Description
Refactor Job Launcher Server job creation to be job-type agnostic by introducing a new create endpoint that accepts a generic payload instead of job-type-specific inputs. The new request should accept: manifestUrl, manifestHash, fundAmount, fundToken, network (existing enum), and taskSize (int > 0). The server must validate the manifest by fetching it and verifying the provided SHA-1 hash (crypto.createHash('sha1').update(data).digest('hex')).
Motivation
Current job creation is coupled to specific job types, which makes the API harder to extend and increases backend branching/maintenance. A manifest-driven, job-type-agnostic create flow simplifies the API contract, moves job-specific details into the manifest, and makes it easier to support new job types without changing the creation endpoint.
Implementation details
- Add a new job creation endpoint (new route/version) and keep response shape aligned with current behavior where possible.
- Define a new create-job DTO with:
manifestUrl: string (URL validation)
manifestHash: string (SHA-1 hex format validation)
fundAmount: number (in payment token)
paymenToken: string ????
fundToken: string (use existing token conventions/enums if available)
network: ExistingNetworkEnum
taskSize: number (integer, > 0)
- Remove
jobType from the new endpoint request payload.
- Implement manifest verification in the creation flow:
- Fetch manifest content from
manifestUrl
- Compute SHA-1 hash using existing utility behavior (
crypto.createHash('sha1').update(data).digest('hex'))
- Reject request if computed hash does not match
manifestHash
- Update job creation service flow to avoid job-type-specific branching at request parsing time (manifest becomes the source of type-specific details).
- Update job entity to remove job type.
- Add/update tests.
- Update docs and examples to document the new endpoint and payload.
Description
Refactor Job Launcher Server job creation to be job-type agnostic by introducing a new create endpoint that accepts a generic payload instead of job-type-specific inputs. The new request should accept:
manifestUrl,manifestHash,fundAmount,fundToken,network(existing enum), andtaskSize(int > 0). The server must validate the manifest by fetching it and verifying the provided SHA-1 hash (crypto.createHash('sha1').update(data).digest('hex')).Motivation
Current job creation is coupled to specific job types, which makes the API harder to extend and increases backend branching/maintenance. A manifest-driven, job-type-agnostic create flow simplifies the API contract, moves job-specific details into the manifest, and makes it easier to support new job types without changing the creation endpoint.
Implementation details
manifestUrl: string(URL validation)manifestHash: string(SHA-1 hex format validation)fundAmount: number(in payment token)paymenToken: string????fundToken: string(use existing token conventions/enums if available)network: ExistingNetworkEnumtaskSize: number(integer,> 0)jobTypefrom the new endpoint request payload.manifestUrlcrypto.createHash('sha1').update(data).digest('hex'))manifestHash