We’ve upgraded to 2018.3.11 in the last couple of days and we’re getting the following error when trying to view the log for a couple of specific deployments (the issue might have been present in previous versions as well, I guess, but we’ve not seen it until today).
To trigger the error, navigate to the specific deployments and click Task Log, then select “Log level - Verbose” and “Log tail = All”. After a few seconds the error below appears.
An unexpected error occurred in Octopus v2018.3.11: "TypeError: Expected "Parse" to be defined"
in u
in t
in withRouter(u)
in n
in div
in div
in t
in div
in t
in div
in TaskLogLines
in div
in div
in a
in t
in withRouter(a)
in div
in div
in div
in a
in t
in withRouter(a)
in div
in div
in div
in a
in t
in withRouter(a)
in div
in div
in section
in t
in div
in a
in t
in withRouter(a)
in div
in d
in div
in div
in t
in t
in div
in div
in n
in t
in t
in withRouter(t)
in t
in t
in t
in t
in t
in t
in t
in withRouter(t)
in t
in t
in t
in t
in t
in t
in div
in div
in MediaQuery
in div
in E
in t
in withRouter(E)
in div
in t
in Connect(t)
in t
in t
in t
in t
in t
in t
in withRouter(t)
in t
in t
in t
in t
in t
in r
in t
in t
in t
in t
in t
in x
in div
in t
in Connect(t)
in t
in t
in t
in t
in t
in t
in t
in t
in Provider
in t
in i
in t
HIDE FULL EXCEPTION
Octopus v2018.3.11
TypeError: Expected "Parse" to be defined
undefined (/node_modules/path-to-regexp/index.js:179:0)
resolveStringPathWithSpaceId (/app/components/Navigation/resolvePathWithSpaceId.tsx:21:38)
resolvePathWithSpaceId (/app/components/Navigation/resolvePathWithSpaceId.tsx:11:11)
onClick (/app/components/Navigation/InternalLink/InternalLink.tsx:45:21)
beginWork (/node_modules/react-dom/cjs/react-dom.production.min.js:149:336)
e (/node_modules/react-dom/cjs/react-dom.production.min.js:182:349)
g (/node_modules/react-dom/cjs/react-dom.production.min.js:183:347)
p (/node_modules/react-dom/cjs/react-dom.production.min.js:184:366)
0;null!==a&&c;){c=!1;if(a.pendingWorkPriority===T||a.pendingWorkPriority>b)c=!0,a.pendingWorkPriority=b;null!==a.alternate&&(a.alternate.pendingWorkPriority===T||a.alternate.pendingWorkPriority>b)&&(c=!0,a.alternate.pendingWorkPriority=b);if(null===a["return"])if (/node_modules/react-dom/cjs/react-dom.production.min.js:188:389)
S (/node_modules/react-dom/cjs/react-dom.production.min.js:187:415)
It only seems to affect the logs for a small number of deployments in specific projects - if I try to view the verbose log for other environments in the same project they load fine, as do the same environment in other projects, and other releases in the same project. And if I try to view the logs for the same deployment with “Verbose / Tail 20” or “Info / All” it loads fine as well.
I’ve used Fiddler to trace the API calls and these load fine in the UI:
All 4 responses parse fine in the Fiddler JSON visualiser, so they’re all valid json. I can probably PM the responses if that would help diagnose the issue?
We’re also getting a slightly different error message in the same circumstances for the deployment log in another project. Again, the UI renders ok for “Info / Tail 20”, “Info / All” and “Verbose / Tail 20” but gives the error below fro “Verbose / All”.
I’m assuming it’s related, but let me know if you’d rather I create a separate ticket for this.
Cheers,
Mike
in u
in t
in withRouter(u)
in n
in div
in div
in t
in div
in t
in div
in TaskLogLines
in div
in div
in a
in t
in withRouter(a)
in div
in div
in div
in a
in t
in withRouter(a)
in div
in div
in div
in a
in t
in withRouter(a)
in div
in div
in div
in a
in t
in withRouter(a)
in div
in div
in section
in t
in div
in a
in t
in withRouter(a)
in div
in d
in div
in div
in t
in t
in div
in div
in n
in t
in t
in withRouter(t)
in t
in t
in t
in t
in t
in t
in t
in withRouter(t)
in t
in t
in t
in t
in t
in t
in div
in div
in MediaQuery
in div
in E
in t
in withRouter(E)
in div
in t
in Connect(t)
in t
in t
in t
in t
in t
in t
in withRouter(t)
in t
in t
in t
in t
in t
in r
in t
in t
in t
in t
in t
in x
in div
in t
in Connect(t)
in t
in t
in t
in t
in t
in t
in t
in t
in Provider
in t
in i
in t
HIDE FULL EXCEPTION
Octopus v2018.3.11
TypeError: Expected "FromBase64String" to be defined
undefined (/node_modules/path-to-regexp/index.js:179:0)
resolveStringPathWithSpaceId (/app/components/Navigation/resolvePathWithSpaceId.tsx:21:38)
resolvePathWithSpaceId (/app/components/Navigation/resolvePathWithSpaceId.tsx:11:11)
onClick (/app/components/Navigation/InternalLink/InternalLink.tsx:45:21)
beginWork (/node_modules/react-dom/cjs/react-dom.production.min.js:149:336)
e (/node_modules/react-dom/cjs/react-dom.production.min.js:182:349)
g (/node_modules/react-dom/cjs/react-dom.production.min.js:183:347)
p (/node_modules/react-dom/cjs/react-dom.production.min.js:184:366)
0;null!==a&&c;){c=!1;if(a.pendingWorkPriority===T||a.pendingWorkPriority>b)c=!0,a.pendingWorkPriority=b;null!==a.alternate&&(a.alternate.pendingWorkPriority===T||a.alternate.pendingWorkPriority>b)&&(c=!0,a.alternate.pendingWorkPriority=b);if(null===a["return"])if (/node_modules/react-dom/cjs/react-dom.production.min.js:188:389)
S (/node_modules/react-dom/cjs/react-dom.production.min.js:187:415)
Pawel_Pabich
(Pawel Pabich)
Made this topic a personal message
3
Thanks for getting in touch! I’ve tried to reproduce the problem but I haven’t been successful. I have a feeling it is specific to your deployment process so I will need a bit more data from you. I made this conversation private so your data will be visible only to me.
If you are comfortable with browser dev tools, can you put a breakpoint on line #179 in path-to-regexp/index.js and output the content of these variables: obj, opts and token. Don’t worry if you don’t know how to do it and I will try to figure out the root cause based on 1) and 2).
I’ve not really used the Chrome debugger before, but I had a bit of a tinker to try to answer your questions, and I think I’ve found a simple repro that you can try.
The issue seems to be that if you have a PowerShell script (inline, or in a step template / script module) which uses static methods (e.g. [myType]::myMethod(...)), under certain circumstances the UI tries to parse the log line containing the PowerShell source code into something meaningful using a dynamic regex, and then complains that the regex called “myMethod” doesn’t match.
To reproduce:
create a new project
add a single Script step with the following inline code: $x = [bool]([bool]::Parse("true"));
create a release
deploy the release
wait for the deployment to complete
view the Task Log for the deployment
select “Log level = Verbose” and “Log tail = All”
wait a few seconds for the error to appear
Note that the “Parse” string in the error is the name of the static method.
The following script (without the first [bool] prefix to cast the result) doesn’t seem to trigger the issue, and the Verbose / All log renders fine:
$x = ([bool]::Parse("true"));
My lightbulb moment was when looking at the breakpoint you suggested - if you scroll up to the “tokensToFunctions” function you’ll see the “tokens” parameter. It took me a while to realise this was our code chopped up into bits:
The call stack shows this is a result of part of the code [bool]::Parse("true" being passed to resolveStringPathWithSpaceId but then I got lost in all the obfuscated and anonymous methods .
Hopefully this is enough for you to reproduce locally - let me know if it doesn’t work for you though.
