TypeError on Verbose deployment log

Hi,

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:

  • /api/tasks/ServerTasks-527998/details?verbose=false - HTTP 200, 7.7kb response
  • /api/tasks/ServerTasks-527998/details?verbose=false&tail=20 - HTTP 200, 6.2kb response
  • /api/tasks/ServerTasks-527998/details?verbose=true&tail=20 - HTTP 200, 10.7kb response

This is the API call made when the UI shows the error:

  • /api/tasks/ServerTasks-527998/details?verbose=true - HTTP 200, 690kb response

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?

Cheers,

Mike

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)

Hi Mike,

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.

Can you please send me the following:

  1. The raw log for both failing deployment tasks
  2. Recording of a session where you cause the UI to crash
  3. 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).

Regards,

Pawel

Hi Pawel,

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:

image

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.

Cheers,

M

Hi Mike,

This is perfect! I was able to reproduce the problem and we will be shipping a fix soon. You can track the progress of our work here.

Regards,

Pawel

Fab. Thanks Pawel.

As there’s no private data in this ticket I’m ok if you want to make it public again so other people can find it if they get the same issue.

Cheers,

M

Thank you.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.