Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • B bull
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 175
    • Issues 175
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 9
    • Merge requests 9
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OptimalBits
  • bull
  • Issues
  • #985
Closed
Open
Issue created Jun 21, 2018 by Administrator@rootContributor

[BUG] Failed jobs don't have original stacktrace when run in separate processes

Created by: Restuta

Description

This is a regression introduced here https://github.com/OptimalBits/bull/commit/7160c06b96ae0d60b6f5358c94f90a9bd759ad00 (in 3.4.2), it results in loss of the original stack trace. Here is an example I grabbed from Arena UI for one of our failed jobs:

bull 3.4.2

Error: [object Object]
    at ChildProcess.handler ([....masked....]/node_modules/bull/lib/process/sandbox.js:25:22)
    at emitTwo (events.js:126:13)
    at ChildProcess.emit (events.js:214:7)
    at emit (internal/child_process.js:772:12)
    at _combinedTickCallback (internal/process/next_tick.js:141:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)

and before 3.4.2 (3.4.0)

Error: email sending failed  
    at [....masked....]/server/app/email/job/send-email.js:9:8
    at Object.statsAsync ([....masked....]/server/lib/hermes/create-hermes-with.js:75:10)
    at statsAsync.next (<anonymous>)
    at statsAsync.tryCatcher ([....masked....]/node_modules/bluebird/js/release/util.js:11:23)
    at PromiseSpawn._promiseFulfilled ([....masked....]/node_modules/bluebird/js/release/generators.js:90:49)
    at Object.statsAsync ([....masked....]/node_modules/bluebird/js/release/generators.js:182:15)
    at P.method ([....masked....]/server/proc/lib/create-job-processor/index.js:121:4)
    at <anonymous>
    at process._tickDomainCallback (internal/process/next_tick.js:228:7)

I tried to understand the original motivation and I sounds like that change was made so promise is not getting rejected with just a message and not error object. But I am still not sure why do we need to do

           process.send({
               cmd: 'failed',
-              value: err
+              value: err.message || err
             });

I'd send a PR to fix that, but I am confused why that change was made in the first place.

Minimal, Working Test code to reproduce the issue.

Use separate process to process jobs with process('*', 'path-to-file.js'). Queue job that throws error, observe that logged error lacks original stack-trace. (Easy to see using Arena UI)

Bull version

3.4.2

Additional information

related issue https://github.com/OptimalBits/bull/issues/893

@manast @jpschober

Assignee
Assign to
Time tracking