[Job Launcher] jobService refactor plan

[portuu3]

Description
The jobService needs to be refactored to improve maintainability and testability. The current structure makes it difficult to write reliable unit tests and isolate dependencies. This issue aims to review the existing implementation and create a plan for incremental refactoring.

Motivation

• The current jobService is tightly coupled, making it hard to test in isolation.
• Lack of clear separation of concerns increases technical debt and complexity.
• Refactoring will allow us to introduce better dependency management, making the service more modular and easier to extend.
• Doing this incrementally ensures that changes can be released without waiting for a full rewrite.

Implementation details

• Review the current implementation and document problem areas.
• Define a plan and create issues to tackle in small, incremental PRs.

[flopez7]

1. New routing-protocol Module

   • All logic for selecting and validating oracles and networks will be moved to a dedicated module for better atomicity.
   • This keeps responsibilities clear and helps maintain any protocol-specific features independently.

2. New Manifest Module

   • This module will expose endpoints to create different types of manifests (currently, CVAT and Fortune).
   • HCaptcha is excluded because they already manage their own manifest externally.
   • Any manifest creation logic in jobService will be removed and placed in this new module.
   • To ensure consistent integration and easy extensibility, define a common interface (e.g., IManifestService) that each specific manifest service (CVAT, Fortune, etc.) implements.
   • This interface might include methods like createManifest(dto), so each new job type can plug into the system seamlessly.

3. Simplifying the JobService

   • The jobService will be limited to specific job actions like creating the job, listing all jobs, job details or cancel jobs.
   • The createJob will only receive the manifestUrl and manifestHash (generated by the Manifest module or provided by the client), then verify the hash or any basic integrity checks (check open question), moving the withdrawal creation logic to the payments module.
   • With these values, it will store the manifest information and payment details (user, chain, oracles, etc.) in the database.

4. Open Question

   • Should payment data (fundAmount, fundCurrency, paymentAmount, paymentCurrency) be included inside the manifest itself, or should these fields be passed directly as parameters to the job-creation endpoint?
   • This decision determines if the manifest also describes the financial terms.

Collaboration Benefit

• With the Manifest module isolated, contributors can simply adjust their new manifest creation logic (implementing the common IManifestService interface).
• Meanwhile, the createJob function in jobService remains the same across all job types, reducing friction and facilitating integration in the future.

[portuu3]

Open Question

• Should payment data (fundAmount, fundCurrency, paymentAmount, paymentCurrency) be included inside the manifest itself, or should these fields be passed directly as parameters to the job-creation endpoint?
  For sure paymentAmount and paymentCurrency should NOT be included. The fundAmount and fundToken, what is the current status? What job types already include them?
  @flopez7

[portuu3]

• HCaptcha is excluded because they already manage their own manifest externally.
  It is going to be required soon

[flopez7]

Open Question

• Should payment data (fundAmount, fundCurrency, paymentAmount, paymentCurrency) be included inside the manifest itself, or should these fields be passed directly as parameters to the job-creation endpoint?
  For sure paymentAmount and paymentCurrency should NOT be included. The fundAmount and fundToken, what is the current status? What job types already include them?
  @flopez7

HCaptcha manifests does not include fundAmount nor fundToken. CVAT manifests includes fund amount as jobBounty. Fortune is the one that includes fundAmount in manifest. I would suggest to leave the manifests as they are right now and add all parameters in CreateJobDto @portuu3

[Dzeranov]

@flopez7

CVAT manifests includes fund amount as jobBounty

jobBounty != fundAmount, it's an approximate reward for an annotator for completing 1 task in this escrow.
Anyway, I think we should get rid of it for the sake of simplicity alongside some other fields. I'll talk about that with Maxim.

[portuu3]

If we create the job in 2 phases we cannot include the fund amount in the manifest. Let's imagine a case where the job is paid with FIAT and the funding token is HMT. Since the balance in USD is not deducted at the time of manifest creation, we don't know how much the amount to be paid in USD will be worth in HMT at the time of the deduction.
So we cannot include fund amount in the manifest with this approach, and I would not include fund token either.
@Dzeranov @flopez7 what do you think?

[Dzeranov]

@portuu3 well, we are not including fund amount in the manifest.
Anyway, this information can be gathered from the escrow itself.
Just a reminder, we will remove job_bounty from the CVAT manifest and calculate an approximate reward on human app based on fund_amount and amount of tasks created per escrow.