fix: forward controlActionCancel to cancelCh in poll-mode fetchAndRunLoop - #1245

I see two issues here:

1. I don't think this is actually going to do what you think it will, because there's no way for the producer to get these job cancel messages when in poll-only mode. You would need to periodically poll the database for all running job IDs to see if they've been cancelled.
2. Repeatedly polling the database to ask if running jobs are still actually running could have substantial overhead, or would at least result in a lot of query noise for something that happens rarely.

Rather than going down this path, I think it's more likely we'd want to think about a non-Postgres notifier option of some kind (i.e. Redis). This would lose transactionality, but would be far more scalable and compatible with non-NOTIFY Postgres environments, dbsql drivers, or other databases.

Another option which we've talked about before is letting you use a pgx listener/notifer even if you're using database/sql for the rest of your driver: #352 This potentially covers some Postgres use cases that leverage database/sql, albeit only if you have access to a conn or pool that does have LISTEN/NOTIFY support (like by bypassing pgbouncer).

Thanks for the detailed explanation. One small clarification: the fix doesn't rely on Postgres NOTIFY at all. JobCancel calls notifyProducerWithoutListenerQueueControlEvent, which — when SupportsListener() == false — does an in-process channel send via TriggerQueueControlEvent directly to the producer. My fix wires that into cancelCh so maybeCancelJob fires. I confirmed this in my setup with logs showing job cancelled remotely immediately after JobCancel.

You're right though that this only works single-process — in a multi-process deployment that channel send never reaches the other server's producer. So it's not a general solution and I understand why you wouldn't want to merge it as-is.

For my use case I'm working around it by polling the contract status from inside Work(). Happy to close this PR if it's not the direction you want to go.

Hey @ata-the-legend, sorry for the delay here! I think your last point in that this is a fairly strict improvement for the in-process poll-only path is a good one. We don't handle the multi-process case, but this'll be useful in some situations.

A couple minor things:

1. Did you consider just calling p.maybeCancelJob(workCtx, msg.JobID) instead of sending to cancelCh? This might have the benefit of just making the code a little more readable/direct without the additional channel hop.
2. Could you add a comment around those lines saying what we've talked about here: this path is only expected to take effect in poll-only mode, and only works for the case of a single process. Multi-process setups will have to wait for the next poll event for a cancel to take effect.
3. Do you want to rebase and add a changelog entry?

Thanks! This code is not too easy to understand, so good stuff.

Thanks for the feedback! Addressed all three points:

• Replaced the cancelCh hop with a direct p.maybeCancelJob call
• Added your suggested comment about poll-only / single-process limitation
• Rebased onto latest master and added a changelog entry

All tests pass.