This polling mechanism to wait for job completion has several significant issues and should be refactored.

1. Blocks the request: Holding the HTTP request open while a background job runs defeats the purpose of using a queue, which is to improve responsiveness. This can lead to request timeouts and poor scalability. The recommended pattern is to return a 202 Accepted response immediately and notify the client of completion asynchronously (e.g., via WebSockets).

2. Race condition: When the job completes, the code fetches the lastIssue. This is a race condition. If multiple issues are created concurrently for the same workspace, this could return the wrong issue.

3. Inefficient: Polling with setTimeout creates unnecessary load on Redis.

If blocking the request is a temporary necessity, you should at least fix the race condition by using the job's return value. The processor already returns the created issue, which is available in job.returnvalue.

Using removeOnFail: true will cause failed jobs to be removed immediately after all retries are exhausted. This makes it very difficult to debug failures in production, as all information about the failed job (including the error reason) is lost. It's highly recommended to keep failed jobs for a period to allow for inspection.

        removeOnFail: {
          age: 24 * 3600, // keep failed jobs for 24 hours
        },

To fix the race condition and inefficient database query, you should use the returnvalue from the completed job, which contains the Issue object returned by the processor. Also, it's good practice to include the failure reason when a job fails.

                const createdIssue = updatedJob.returnvalue as Issue;
                if (createdIssue) {
                  resolve(createdIssue);
                } else {
                  reject(new Error('Created issue not found in job result'));
                }
              } else if (state === 'failed') {
                reject(new Error(`Issue creation failed: ${updatedJob.failedReason}`));

Removing completed jobs after only 5 seconds is quite aggressive. This leaves a very short window to inspect recently completed jobs for auditing or debugging. It's advisable to use a longer duration. For example, 1 hour (3600 seconds).

The ISSUE_CREATION queue is being registered here, but it has already been registered in IssuesModule. Since both IssuesModule and JobsRegistryModule are global, this registration is redundant. It's cleaner to register a queue in a single location, typically in the module that is the primary producer of jobs for that queue.