The new clean-job-family tracking in src/jd_client/mining_downstream/mod.rs currently records every NewExtendedMiningJob in job_template_ids,
including future jobs.
That is too broad for the stale-share guard. In the underlying channel logic, future jobs are not valid share targets until SetNewPrevHash promotes
them into the valid-job set. Until then, on_submit_shares_extended() resolves shares through get_valid_job(), which only knows about current valid
jobs.
This creates a gap:
- A future NewExtendedMiningJob arrives.
- remember_template_job() stores its job_id in job_template_ids.
- A miner submits a share for that future job_id before SetNewPrevHash.
- share_uses_stale_job() returns false because the job is tracked.
- The share then fails later as ShareDoNotMatchAnyJob.
- match_send_to() only logs that case, so no SubmitSharesError is sent back downstream.
Impact
- Invalid future-job shares are no longer rejected deterministically at the stale-share boundary.
- Downstream miners may not receive an explicit error for those shares.
- Rejection behavior becomes inconsistent: some invalid jobs return SubmitSharesError, while future-job shares are only logged.
Expected behavior
A share for a future job should be rejected immediately as not part of the current valid clean-job family, and the miner should receive a
downstream error response.
Actual behavior
A future-job share bypasses the stale guard, fails later as ShareDoNotMatchAnyJob, and is only logged.
Affected areas
- src/jd_client/mining_downstream/mod.rs
- share_uses_stale_job()
- remember_template_job()
- handling of Error::ShareDoNotMatchAnyJob in match_send_to()
Suggested fix
Only treat job IDs from the current valid clean-job family as non-stale. Future jobs should be tracked separately, or otherwise excluded from
job_template_ids until they are activated by SetNewPrevHash. As a fallback, if a share hits ShareDoNotMatchAnyJob for a tracked future job, convert
that into an explicit downstream SubmitSharesError instead of only logging it.
The new clean-job-family tracking in src/jd_client/mining_downstream/mod.rs currently records every NewExtendedMiningJob in job_template_ids,
including future jobs.
That is too broad for the stale-share guard. In the underlying channel logic, future jobs are not valid share targets until SetNewPrevHash promotes
them into the valid-job set. Until then, on_submit_shares_extended() resolves shares through get_valid_job(), which only knows about current valid
jobs.
This creates a gap:
Impact
Expected behavior
A share for a future job should be rejected immediately as not part of the current valid clean-job family, and the miner should receive a
downstream error response.
Actual behavior
A future-job share bypasses the stale guard, fails later as ShareDoNotMatchAnyJob, and is only logged.
Affected areas
Suggested fix
Only treat job IDs from the current valid clean-job family as non-stale. Future jobs should be tracked separately, or otherwise excluded from
job_template_ids until they are activated by SetNewPrevHash. As a fallback, if a share hits ShareDoNotMatchAnyJob for a tracked future job, convert
that into an explicit downstream SubmitSharesError instead of only logging it.