Worker-Induced Denial-of-Service in Deployment Requests Due to Lack of a Cancellation Mechanism
The BlueprintCore contract enforces a single deployment request per project by using a check in the deploymentRequest function:
require(projects[projectId].requestDeploymentID == 0, "deployment requestID already exists");Once a worker picks up the deployment request via the submitDeploymentRequest function, the contract sets the request status to Pickup and assigns the worker's address:
require(requestDeploymentStatus[requestID].status != Status.Pickup, "requestID already picked by another worker");
requestDeploymentStatus[requestID].status = Status.Pickup;
requestDeploymentStatus[requestID].deployWorkerAddr = msg.sender;There is no mechanism to cancel or reset the request if the assigned worker fails to submit the deployment proof through submitProofOfDeployment, leaving the request in an indefinite Pickup state. Consequently, the project's deployment process becomes permanently stalled, as further deployment requests cannot be initiated because the project's requestDeploymentID remains set.
Primary Root Cause: The root cause is the contract's design, which permits only one active deployment request per project and lacks a timeout or cancellation function to reset a stalled request when the assigned worker does not complete the process.
Impact: The project owner cannot progress the deployment, effectively halting the project lifecycle. Funds or NFT-based agent creation fees become unusable as the deployment never completes.
Mitigation: Implement a timeout mechanism that allows the deployment owner to cancel and reset a stalled deployment request if no proof is submitted within a defined period (e.g., 7 days).