Skip to content

fix: key inherited jobs by the provider's class - #39

Merged
kamilmysliwiec merged 1 commit into
masterfrom
fix/inherited-job-keys
Oct 22, 2026
Merged

kamilmysliwiec merged 1 commit into
masterfrom
fix/inherited-job-keys

Conversation

@kamilmysliwiec

Copy link
Copy Markdown
Member

A job inherited from a base class now gets its default key and lease from the provider's class (SalesReport.run, StockReport.run), not from the class that declares the method. The startup collision check now works per instance, so a useExisting alias of the same instance is not counted as a second job.

Two behavior changes:

  • Subclassed jobs get new default keys, so during the rolling deploy that ships this, one run can overlap between old and new instances. Setting key explicitly avoids it.
  • One class provided twice without key now fails at startup, as two classes with the same default key already did.

Closes #38

A method decorated with @OnOneInstance() or @WithoutOverlapping() on a
base class took its default key from the class that declares it, so
every subclass shared one run lock and one lease: one subclass's runs
were skipped while another's ran, and the startup check, which compared
job definitions, never saw two jobs.

The default key, the lease and the log lines now follow the instance's
class (SalesReport.run, StockReport.run), and the collision check is per
instance, so one class provided twice without a key fails at startup
too. A `useExisting` alias of the same instance is not a second job.

Closes #38
@kamilmysliwiec
kamilmysliwiec merged commit 6d92a66 into master Oct 22, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Subclasses share the lock key of an inherited @WithoutOverlapping() method, and one run is skipped without a startup error

1 participant