Populate bid pricing details on job creation#4949
Conversation
Previously we'd only populate the price as part of the scheduler cycle. This meant newly created jobs would have an empty price until it was populated as part of the scheduler cycle. This was previously completely fine, but we plan to have an async scheduling cycle where we can't guarentee the scheduler cycle will have set the price on the jobs before the scheduling sees the jobs - This change should mean at all times the jobs in the jobdb that have the same queue/priceband consistently have the prices set - This will mean the async scheduling cycle can safely assume job prices are set The approach chosen was to simply set a price snapshot on the jobdb, I can then use this to get the price - This was chosen because it is simple - It leads the way for if we want to be smarter about what jobs we update on snapshot updates - Now we have the previous snapshot used on the jobdb, we could compare the diff and only update jobs impacted by the changes. Which would be far more efficient than now - which simply updates all jobs regardless of if the bids change Signed-off-by: JamesMurkin <jamesmurkin@hotmail.com>
Signed-off-by: JamesMurkin <jamesmurkin@hotmail.com>
Greptile SummaryThis PR populates bid pricing details on job creation by storing a
Confidence Score: 5/5Safe to merge — the change is well-scoped, the snapshot is applied defensively with a map clone, and all new code paths are covered by tests. The snapshot is stored and committed through the existing transactional model, so there are no new concurrency hazards. The previously swallowed initialisation error is now correctly propagated. NewJob always initialises bidPricesPool to a non-nil empty map when no matching snapshot entry exists, which is the safe default. Tests cover commit/abort semantics and all edge cases for price population. No files require special attention. Important Files Changed
Sequence DiagramsequenceDiagram
participant App as schedulerapp.Run()
participant PPC as BidPriceProvider
participant JDB as JobDb
participant Sched as Scheduler.updateJobPrices()
participant Recon as reconciliation.NewJob()
App->>PPC: Initialise()
App->>PPC: GetBidPrices() [populateInitialBidPrices]
PPC-->>App: BidPriceSnapshot
App->>JDB: WriteTxn → SetBidPriceSnapshot → Commit
loop Scheduler cycle
Sched->>PPC: GetBidPrices()
PPC-->>Sched: updatedBids
Sched->>JDB: txn.Upsert(updatedJobs)
Sched->>JDB: txn.SetBidPriceSnapshot → Commit
end
loop Job reconciliation
Recon->>JDB: NewJob(queue, priceBand, ...)
JDB->>JDB: read bidPriceSnapshot.GetPrice(queue, band)
JDB-->>Recon: "Job{bidPricesPool: clonedPrices}"
end
Reviews (5): Last reviewed commit: "Merge branch 'master' into jobdb_bid_sna..." | Re-trigger Greptile |
Signed-off-by: JamesMurkin <jamesmurkin@hotmail.com>
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Signed-off-by: JamesMurkin <jamesmurkin@hotmail.com>
Signed-off-by: JamesMurkin <jamesmurkin@hotmail.com>
Signed-off-by: JamesMurkin <jamesmurkin@hotmail.com> # Conflicts: # internal/scheduler/schedulerapp.go
Previously we'd only populate the price as part of the scheduler cycle.
This meant newly created jobs would have an empty price until it was populated as part of the scheduler cycle.
This was previously completely fine, but we plan to have an async scheduling cycle where we can't guarentee the scheduler cycle will have set the price on the jobs before the scheduling sees the jobs
The approach chosen was to simply set a price snapshot on the jobdb, it can then use this to get the price, this approach was chosen because: