Summary
The allocation_middleware in crates/service/src/middleware/allocation.rs only handles V1 receipts (SignedReceipt), not V2 receipts (TapReceipt::V2). This causes attestation verification failures on the gateway when deployments have multiple allocations (active + recently closed).
Problem
When processing a V2 receipt, the middleware does not extract the allocation from the receipt's collection_id. Instead, it falls back to looking up an allocation by deployment_id using the deployment_to_allocation map. For deployments with multiple allocations, this may return a different allocation than the one specified in the receipt.
Current code (crates/service/src/middleware/allocation.rs:42-54):
pub async fn allocation_middleware(
State(my_state): State<AllocationState>,
mut request: Request,
next: Next,
) -> Response {
if let Some(receipt) = request.extensions().get::<SignedReceipt>() {
// Only handles V1 receipts
let allocation = receipt.message.allocation_id;
request.extensions_mut().insert(Allocation(allocation));
} else if let Some(deployment_id) = request.extensions().get::<DeploymentId>() {
// Falls through here for V2 receipts
if let Some(allocation) = my_state.deployment_to_allocation.borrow().get(deployment_id) {
request.extensions_mut().insert(Allocation(*allocation));
}
}
next.run(request).await
}
Result:
- Gateway sends V2 receipt with allocation
0xABC in collection_id
- Indexer-service looks up allocation by deployment, gets
0xDEF
- Indexer signs attestation with
0xDEF's key
- Gateway verifies against
0xABC (from the receipt it sent)
- Verification fails:
BadResponse(bad attestation: recovered signer is not expected - recovered signer is not expected)
Summary
The
allocation_middlewareincrates/service/src/middleware/allocation.rsonly handles V1 receipts (SignedReceipt), not V2 receipts (TapReceipt::V2). This causes attestation verification failures on the gateway when deployments have multiple allocations (active + recently closed).Problem
When processing a V2 receipt, the middleware does not extract the allocation from the receipt's
collection_id. Instead, it falls back to looking up an allocation bydeployment_idusing thedeployment_to_allocationmap. For deployments with multiple allocations, this may return a different allocation than the one specified in the receipt.Current code (
crates/service/src/middleware/allocation.rs:42-54):Result:
0xABCincollection_id0xDEF0xDEF's key0xABC(from the receipt it sent)BadResponse(bad attestation: recovered signer is not expected - recovered signer is not expected)