We just had an issue with the following logs:

2023-08-10 22:59:45.367  WARN tokio-runtime-worker parachain::dispute-coordinator: Candidate 0x340ca58da210113c62351725f34a031924772af9b2967987974344bc1a0e2bec considered invalid: BadParent
2023-08-10 22:59:45.366  WARN tokio-runtime-worker parachain::runtime-api: cannot query the runtime API version: Api called for an unknown Block: Header was not found in the database: 0x67541ead0a80909b695bd5d0a4ad61422e7a927b541a91adf0004059ffdc02a7
2023-08-10 22:59:45.366  WARN tokio-runtime-worker parachain::candidate-validation: Failed to acquire executor params for the session validation_code_hash=0x9bb8ab583eaf6a4caa1b0c57c123a697b0dfe7a5935ffff7726b9f359ccc59ad para_id=Id(2123)

Not being able to participate in a dispute because we could not find the relay parent is not ideal. We want to be able to get backers slashed, even if their malicious candidate only resides on some dead fork. dispute-coordinator and dispute-distribution are already pretty robust against issues caused by being out of sync. In particular we pre-fetch session info based on active leaves. Therefore, if the exact relay parent of a candidate was missing, we would still succeed in fetching needed session information. The above revealed a weakness in fetch execution environment parameters, so this should be made as robust.

Subsystems requesting candidate validation all already know the SessionIndex and can just pass it into candidate-validation, avoiding the need to fetch it there, removing errors for pruned/not yet available relay chain blocks.

Candidate validation can then use any current leaf to fetch any data for that SessionIndex it might need to do the actual validation.