Common Job spec reporting via Beholder - #23227
Draft
skudasov wants to merge 3 commits into
Draft
Conversation
Contributor
|
✅ No conflicts with other open PRs targeting |
Contributor
|
I see you updated files related to
|
|
… reporter Fold core/services/cljobinfo into the existing nodestatusreporter/jobspec service instead of adding a parallel reporter. CLJobInfo is now emitted for every job regardless of type, alongside the unchanged OCR2-only JobSpecEvent track. application.go and the [JobSpecReporter] config are unchanged. Requires: smartcontractkit/chainlink-protos#432 RANE-4655
jmank88
reviewed
Sep 4, 2026
Comment on lines
+49
to
+50
| ProposedAt time.Time | ||
| ApprovedAt time.Time |
Contributor
There was a problem hiding this comment.
Is there any risk/ambiguity with using time.Time as opposed to a unix ms int64, for example?
Collaborator
There was a problem hiding this comment.
updated to account for this risk, but used google.protobuf.Timestamp
chainlink-protos changes: smartcontractkit/chainlink-protos@6acc8ef
chainlink changes: a66cc6d
jmank88
approved these changes
Sep 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Emits every job the node runs as
CLJobInfotelemetry on Beholder — job identity, JobDistributor provenance, and the complete definition as TOML
Requires
common.v1.CLJobInfo.This PR does not compile until that merges and
go.modis bumped.What changed
Revised after review feedback and the 2026-09-02 sync. The previous revision added a new
core/services/cljobinfopackage and a second service inapplication.go. This revisionfolds the generic reporting into the existing
core/services/nodestatusreporter/jobspecservice, which already does this for one job type.
One service, one
job.Listenerregistration, one poll loop, two emission tracks:CLJobInfo(new)JobSpecEvent(existing)EnabledOCR2PluginTypesA failure on one track never suppresses the other.
application.gois untouched — the service is already wired and already receivescsaPubKeyHex,static.Version,hostnameandfeedsORM.Why here and not in
feeds/service.goThe review asked to emit this from where we already hook into JD and sync node info
(
feeds/service.go, next toSyncNodeInfo), reusing existing types.Agreed on the principle — no third parallel job-telemetry utility. But that specific
location doesn't work:
nodestatusreporter/jobspecimportsfeedsforfeeds.ORM, so thefeeds service cannot call the reporter unless the reporter moves into
feeds.feedsServiceis aNullServicewhenFeature.FeedsManagerisoff, so telemetry would silently stop on those nodes.
ApproveSpec,CancelSpec,DeleteJob). Jobs created via CLI, UI or TOML on disk would be invisibleunless the spawner listener is kept anyway — which makes the hooks redundant.
feedshas no Beholder dependency today.nodestatusreporter/jobspecis already "the place where we do this": same Beholderemitter, same
job.Listenercreate/delete triggers, sameActiveJobs()sweep, same nodeidentity fields, and it already reads
feeds.ORMfor job-proposal lifecycle. This PRgeneralises it rather than adding a sibling.
On the "call the sync hook whenever changes are made" pattern: jobs already have an event
bus,
job.Spawner.RegisterListener, which fires for both JD-driven and non-JD changes.syncNodeInfoWithRetryexists because chain configs have no such event and because thewsrpc destination can be disconnected; Beholder is fire-and-forget, so there is no
connection to retry against and nothing equivalent to add.
Proto reuse
Not available. Checked
orchestrator/feedsmanager,job-distributor/v1/jobandjob-distributor/v1/node— none models a job's contents. JD carries the spec as anopaque TOML string (
ProposeJobRequest.spec,Proposal.spec), sospec_tomlmatchesJD's own representation rather than inventing a new one.
What we do reuse is the join key. New optional fields —
feeds_manager_id,remote_uuid,spec_version,proposed_at,approved_at— carry JD provenance, withremote_uuidlinking aCLJobInfoback toapi.job.v1.Job.uuid. They are unset for jobsthat did not arrive via a job proposal, which is how a consumer distinguishes a JD-managed
job from a directly-created one.
Behaviour and config
[JobSpecReporter]Enabled(defaultfalse) andPollingInterval(default1h). No config schema change.EnabledOCR2PluginTypescontinues to gate the legacy OCR2 track only; the generic trackignores it by design.
JobSpecEventconsumers.Known gap
In
ApproveSpec,jobSpawner.CreateJobruns inside the transaction, beforeorm.ApproveSpeccommits — so theCREATEevent for a freshly approved job can lack JDprovenance until the next heartbeat fills it in. Fixing this properly means moving the
spawner call out of the transaction; out of scope here.
Follow-up
Once SOT confirms
CLJobInfocovers what the existing data-feeds consumers need,ShouldEmit,EmitForJob,buildEventand theeventspackage can be deleted inplace — no wiring or config changes needed.