Remove unnecessary JobId parameter from spawn_unique

[nicolasburtey]

Context

From PR review discussion on lana-bank#4986.

The JobId parameter passed to spawn_unique is only meaningful on the first ever call, when no job row exists yet and the ID becomes the primary key. On every subsequent call (the common case), it's generated and silently discarded.

All callers always write job::JobId::new() — a fresh random UUID every time — which means the passed-in ID carries no semantic value. spawn_unique could simply generate the ID internally.

Current (suboptimal)

spawner.spawn_unique(job::JobId::new(), HourlyProducerJobConfig { ... }).await?;

Proposed

spawner.spawn_unique(HourlyProducerJobConfig { ... }).await?;

This would simplify the API and remove a parameter that provides no value to callers.

Related: #84

/cc @HonestMajority

[HonestMajority]

This would simplify the API and remove a parameter that provides no value to callers.

I do not agree that the parameter provides no value. The value for the caller to provide the JobId as a parameter is that the caller can choose to generate a deterministic JobId, or use an ID of some existing entity, to manage idempotency or as a convenient way of being able to look up jobs in the future through querying for a deterministic JobId.

I do understand the point about that it can be slightly confusing that the second time we call spawn_unique, we just ignore whatever the provided JobId is passed - if there is already an existing job of that type. The one problem I can see with the current behaviour is that the spawn_unique silently succeeds in this case, while ignoring the new JobId. And if a client/caller want to keep track of this job, and stores the JobId it passed the second time - to be able to query for it later, that JobId is actually wrong.

In my opinion, a better improvement of the API would be that spawn_unique should return an error instead of silently succeeding on conflicts. That way, callers can know what happened, and choose how to handle it.