[TRI-1135] Add job management API endpoints

[ericallam]

We need to flesh out our API to allow you to manage jobs and runs:

• Get a list of runs for a specific job (with filtering for status, environment, etc.)
• Get task data for a specific run
• Cancel a run
• Retry a run
• Resume a run
• Test a job

These would ideally all be exposed via the TriggerClient class and would require the Server API Key to access.

_TRI-1135

[ericallam]

/bounty $200

[algora-pbc[bot]]

💎 $200 bounty • Trigger.dev (YC W23)

Steps to solve:

1. Start working: Comment /attempt #388 with your implementation plan
2. Submit work: Create a pull request including /claim #388 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Additional opportunities:

• 🔴 Livestream on Algora TV while solving this bounty & earn $200 upon merge! Make sure to have your camera and microphone on. Comment /livestream once live

Thank you for contributing to triggerdotdev/trigger.dev!

Add a bounty • Share on socials

[fvckDesa]

/attempt #388

Options

• Cancel my attempt

[neo773]

/attempt #388

Options

• Cancel my attempt

[algora-pbc[bot]]

@fvckDesa is already attempting to complete #388 and claim the bounty. If you attempt to complete the same issue, there is a chance that @fvckDesa will complete the issue first, and be awarded the bounty. Try discussing with @fvckDesa and potentially collaborating on the same solution versus creating an alternate solution.

[matt-aitken]

@ericallam you can already get runs for a job, and get info about a run using the SDK

[ericallam]

@matt-aitken private data or just public?

[ericallam]

BTW the reason I created this issue is because of this scenario:

https://github.com/triggerdotdev/trigger.dev/issues/386#issuecomment-1690604407

[ericallam]

Hold off on working on this for now, I think there's a discussion that needs to be had first about if it makes sense to use the Project API Key's for these management API endpoints or if we should have another type of API key that works across projects & environments. A sort of "Personal Access Token" type API Key, similar to the Supabase Management API works

[Chigala]

/attempt #388

Options

• Cancel my attempt

[matt-aitken]

@Chigala @fvckDesa don't work on this. We need to think more about how this works.

[ericallam]

Yea this feature will require a new type of API Key called a Personal Access Token:

These API Keys have authorization the "Management APIs", some of which are mentioned above. The endpoints should be different from our current API endpoints (maybe something like /manage/api/v1/...)

You should be able to create multiple personal access tokens, and we don't create one for you by default. The PAT should look like tr_pat_XXXXXXXXXXXXXX.

PATs should also be revokable. They should be stored in a new table called PersonalAccessToken and belong to a specific User. The PersonAccessToken table should have a lastAccessedAt column that should be updated anytime the PAT is used and that value should be displayed in the list of PATs

[Chigala]

@ericallam using personal access tokens for the management APIs makes more sense. This is how the PAT table would be modelled right?

model PersonalAccessToken {
  id                String      @id @default(cuid())
  token             String    @unique
  revoked           Boolean   @default(false)
  revokedAt         DateTime?
  lastAccessedAt    DateTime
  userId            String    
  user              User      @relation(fields: [userId], references: [id], onDelete: Cascade, onUpdate: Cascade)
}

When a PAT is revoked, should we just take this my approach of a soft delete or remove the token from the DB?

[ericallam]

Yea I think you don't need the revoked column, you can just use revokedAt. Also lastAccessedAt should be optional. everything else looks good

[Chigala]

Ohk, Thanks. Are there any more changes on your end about this? If no, that means I can start working on it right?

[ericallam]

@Chigala I would let @neo773 take this one for now, as he started on it last night

[Chigala]

That's ohk

[algora-pbc[bot]]

@fvckDesa: Reminder that in 7 days the bounty will become up for grabs, so please submit a pull request before then 🙏

[algora-pbc[bot]]

@Chigala: Reminder that in 7 days the bounty will become up for grabs, so please submit a pull request before then 🙏

[dennismzia]

this seems easy why and august in the tech world is ages ago so how comes no one has finished it. or claimed the reward anyways is this still open ?

[neo773]

@dennismzia I had a PR for this but the trigger management have put it on hold for now.

[andrewlu0]

I would really benefit from this functionality as right now our end users have no way of retrying a job run if it fails. Either a management API or even returning the run's payload info in getRun() or useEventRunDetails(), would enable users to retry failed runs. Is there any update on this?

[ericallam]

@andrewlu0 we've recently released a new API for exposing run data to the public called Run Statuses:

https://trigger.dev/docs/documentation/guides/react-hooks-statuses

Would that help in your case?

[algora-pbc[bot]]

@VirtualDharm: The Trigger.dev (YC W23) team prefers to assign a single contributor to the issue rather than let anyone attempt it right away. We recommend waiting for a confirmation from a member before getting started.

[rishi-raj-jain]

@ericallam Can I work on this?

[neo773]

@rishi-raj-jain They put it on hold since they needed a few prerequisite changes prior to merging my PR. Not sure what the status is now. You could use my closed PR as base if you'd wish https://github.com/triggerdotdev/trigger.dev/pull/406

[algora-pbc[bot]]

@vinfinity7: The Trigger.dev (YC W23) team prefers to assign a single contributor to the issue rather than let anyone attempt it right away. We recommend waiting for a confirmation from a member before getting started.

[xiaoqixing]

/attempt #388

[algora-pbc[bot]]

@xiaoqixing: The Trigger.dev (YC W23) team prefers to assign a single contributor to the issue rather than let anyone attempt it right away. We recommend waiting for a confirmation from a member before getting started.

[madhukaraman]

/attempt #388

[algora-pbc[bot]]

@madhukaraman: The Trigger.dev (YC W23) team prefers to assign a single contributor to the issue rather than let anyone attempt it right away. We recommend waiting for a confirmation from a member before getting started.

[michaelajilore]

/attempt #388

Options

• Cancel my attempt

[algora-pbc[bot]]

@michaelajilore: The Trigger.dev (YC W23) team prefers to assign a single contributor to the issue rather than let anyone attempt it right away. We recommend waiting for a confirmation from a member before getting started.

[Bhavyajain21]

Can I be assigned? @matt-aitken

[Bhavyajain21]

/attempt #388

Options

• Cancel my attempt

[algora-pbc[bot]]

@Bhavyajain21: The Trigger.dev (YC W23) team prefers to assign a single contributor to the issue rather than let anyone attempt it right away. We recommend waiting for a confirmation from a member before getting started.

[Sanskar711]

@ericallam is this issue still open can i work on it??

[rituraj12797]

/attempt #388

Options

• Cancel my attempt

[algora-pbc[bot]]

@rituraj12797: The Trigger.dev (YC W23) team prefers to assign a single contributor to the issue rather than let anyone attempt it right away. We recommend waiting for a confirmation from a member before getting started.

[0xa48rx394r83e9]

This looks like an intriguing feature to build, and I'm eager to work on it, but I'd like to just clarify that the bounty is still open and that the scope/parameters of the bounty haven't changed (since it's been nine months).

[RamitVishwakarma]

/attempt 388

Options

• Cancel my attempt

[algora-pbc[bot]]

@RamitVishwakarma: The Trigger.dev (YC W23) team prefers to assign a single contributor to the issue rather than let anyone attempt it right away. We recommend waiting for a confirmation from a member before getting started.