Error deploying Background Jobs Worker to AWS via FlightControl

Get Help and Help Others
1

Hey all, I’ve created some Background Jobs and I’m attempting to deploy them for testing in my dev environment at AWS through FlightControl, and I’m getting the following error:

JobsLibNotFoundError: api/src/lib/jobs.{ts,js} not found. Run yarn rw setup jobsto create this file and configure background jobs. Already did that? You'll need to runyarn rw devoryarn rw build before you can start the job workers!

Here’s what the worker-related portion of my FlightControl.json file looks like:

          "id": "worker",
          "name": "Worker",
          "type": "worker",
          "buildType": "nixpacks",
          "cpu": 0.25,
          "memory": 0.5,
          "minInstances": 1,
          "maxInstances": 1,
          "buildCommand": "yarn rw setup jobs",
          "startCommand": "yarn rw jobs start",
          "envVariables": {
            "DATABASE_URL": {
              "fromService": {
                "id": "db",
                "value": "dbConnectionString"
              }
            }
          }
        }

I thought the buildCommand might address the error but it does not, I get the same error on subsequent attempts.

I appreciate any help anyone can offer!

Here’s the full error in case it’s helpful:

JobsLibNotFoundError: api/src/lib/jobs.{ts,js} not found. Run `yarn rw setup jobs` to create this file and configure background jobs. Already did that? You'll need to run `yarn rw dev` or `yarn rw build` before you can start the job workers!
8:07:36 AM     at loadJobsManager (/app/node_modules/@redwoodjs/jobs/dist/loaders.js:43:11)
8:07:36 AM     at main (/app/node_modules/@redwoodjs/jobs/dist/bins/rw-jobs.js:187:59)
8:07:36 AM     at Object.<anonymous> (/app/node_modules/@redwoodjs/jobs/dist/bins/rw-jobs.js:240:3)
8:07:36 AM     at Module._compile (node:internal/modules/cjs/loader:1358:14)
8:07:36 AM     at Module._extensions..js (node:internal/modules/cjs/loader:1416:10)
8:07:36 AM     at Module.load (node:internal/modules/cjs/loader:1208:32)
8:07:36 AM     at Module._load (node:internal/modules/cjs/loader:1024:12)
8:07:36 AM     at Module.require (node:internal/modules/cjs/loader:1233:19)
8:07:36 AM     at require (node:internal/modules/helpers:179:18)
8:07:36 AM     at file:///app/node_modules/@redwoodjs/core/dist/bins/rw-jobs.js:8:1
8:07:37 AM Error: Command failed with exit code 1: yarn rw-jobs start
8:07:37 AM     at makeError (/app/node_modules/execa/lib/error.js:60:11)
8:07:37 AM     at module.exports.sync (/app/node_modules/execa/index.js:194:17)
8:07:37 AM     at module.exports.commandSync (/app/node_modules/execa/index.js:235:15)
8:07:37 AM     at handler (/app/node_modules/@redwoodjs/cli/dist/commands/jobsHandler.js:54:24)
8:07:37 AM     at Object.handler (/app/node_modules/@redwoodjs/cli/dist/commands/jobs.js:46:10)
8:07:37 AM     at async runYargs (/app/node_modules/@redwoodjs/cli/dist/index.js:154:3)
8:07:37 AM     at async /app/node_modules/@redwoodjs/cli/dist/index.js:106:7
8:07:37 AM     at async main (/app/node_modules/@redwoodjs/cli/dist/index.js:95:3)
2

Modified the build command to:

"buildCommand": "yarn rw setup jobs && yarn rw build"

…and the above-mentioned error is gone, but FlightControl’s UI shows the following:

Failed to update ECS service

The following error was returned by AWS: Essential container in task exited

…and the logs below that ^^^ message show only this:

8:39:41 AM {"level":40,"time":1727354381405,"pid":124,"hostname":"ip-xxx.ec2.internal","msg":"Starting RedwoodJob Runner at 2024-09-26T12:39:41.214Z..."}
8:39:41 AM {"level":40,"time":1727354381406,"pid":124,"hostname":"ip-xxx.ec2.internal","msg":"Starting 1 worker(s)..."}
3

Hey @nullsett :wave:

Two things come to mind:

  1. We might just need the yarn rw build for the buildCommand? If your project already has jobs setup then I would be confused as to why we’d need to do so again.
  2. You might have to use yarn rw jobs work rather than yarn rw jobs start. I think using start which starts the workers, detatches them and then exits might make the container look like it stopped - because the command exited.
1 Like
4

My man! That looks to have done the trick, deployed with no errors. Thanks so much for the response!

2 Likes
5

Awesome! Glad I could help. It’s excellent to have people like yourself try out the new background jobs feature so any feedback and experiences, good or bad, are awesome to hear about!

1 Like