Log fetch reports per worker

[fbac]

Log fetch reports per worker by moving payerreport.Store.FetchReports to Debug level and adding Debug logs in payerreport.workers.AttestationWorker, payerreport.workers.GeneratorWorker, and payerreport.workers.SubmitterWorker methods

This change adjusts logging around report fetching across the payer report workers. It lowers the log level of the store fetch to Debug and adds new Debug logs with contextual fields in worker methods.

• Lower the log level of payerreport.Store.FetchReports from Info to Debug and update message casing in store.go
• Add a Debug log before fetching reports needing attestation in payerreport.workers.AttestationWorker.findReportsNeedingAttestation and before fetching previous reports with originator_node_id and start_sequence_id in payerreport.workers.AttestationWorker.getPreviousReport in attestation.go
• Add Debug logs in payerreport.workers.GeneratorWorker.maybeGenerateReport with node_id and existing_end_sequence_id, and in payerreport.workers.GeneratorWorker.getLastSubmittedReport with node_id in generator.go
• Add a Debug log before fetching reports to submit in payerreport.workers.SubmitterWorker.SubmitReports in submitter.go

📍Where to Start

Start with the log level change in payerreport.Store.FetchReports in store.go, then review the added Debug logs in worker methods beginning with payerreport.workers.AttestationWorker.findReportsNeedingAttestation in attestation.go.

---

📊 Macroscope summarized 36d6a60. 4 files reviewed, 4 issues evaluated, 4 issues filtered, 0 comments posted

🗂️ Filtered Issues

pkg/payerreport/workers/generator.go — 0 comments posted, 1 evaluated, 1 filtered

• line 116: Time-of-check to time-of-use race can generate duplicate reports in maybeGenerateReport. Between fetching lastSubmittedReport and subsequently fetching existingReports filtered by SubmissionPending, a concurrent submitter can transition a report from pending to submitted. This makes the pending check miss the just-submitted report and allows generateReport to run, creating a duplicate report for the same range. The code even notes this hazard in comments. To fix, enforce a stronger atomicity: e.g., perform both checks and the potential creation within a single DB transaction using appropriate locks (SELECT ... FOR UPDATE) and/or a unique constraint on the report interval per originator, and handle uniqueness violations by re-reading; or take an advisory/row lock around the sequence window. [ Out of scope ]

pkg/payerreport/workers/submitter.go — 0 comments posted, 3 evaluated, 3 filtered

• line 73: SubmitReports inconsistently uses contexts: it acquires the advisory locker with w.payerReportStore.GetAdvisoryLocker(w.ctx) using the worker’s long-lived w.ctx, but uses the passed ctx for store operations (FetchReports, SetReportSubmissionRejected, SetReportSubmitted). This can lead to cancellation and timeout mismatches where the advisory lock acquisition/holding ignores the caller’s cancellation, or store operations cancel while the lock continues to be held. This inconsistency can cause prolonged lock holding or partial work when ctx is canceled. The function should use a consistent context, typically the passed ctx, for all operations, or document and intentionally separate lifetimes with explicit handling. [ Low confidence ]
• line 101: The loop assumes all elements in reports are non-nil, but no guard enforces this. If FetchReports returns a slice containing a nil *PayerReportWithStatus, then payerreport.AddReportLogFields(w.log, &report.PayerReport) will dereference report and panic. Subsequent uses like report.ID.String() and passing report to w.submitReport(report) will also panic. You should add a nil check per element before dereferencing or using the report. [ Low confidence ]
• line 141: Errors from SetReportSubmitted are only logged at Warn level and not propagated via the function return (latestErr is not set). This means the worker can return nil even when the report’s submitted state failed to persist, leading to inconsistent state and silent failure from the caller’s perspective (Start only logs returned errors). While the comment mentions a race the store should handle, failures unrelated to the race (e.g., DB errors) are suppressed. Consider including the error in the log (zap.Error(err)) and propagating it via latestErr to ensure visibility and retries/alerts behave correctly. [ Low confidence ]

[graphite-app]

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• Queue - adds this PR to the back of the merge queue
• Hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.