OpenFn / OpenFn/kit

Engine: tidy resolvers

Open
#419 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

tech debt
Dominant language
TypeScript
Stars
21
Forks
23
Avg merge
1d 22h
Merged PRs (30d)
17

Description

Should the engine accept resolvers in its constructor (one set of resolvers works for all credentials and dataclips), or should they be passed to each execute call?

At the moment they are passed on execute, but suddenly that seems strange to me (actually, I think I've accidentally been supporting both APIs all week and the point is I need to consolidate on just one)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the engine constructor and execute call sites to compare how resolvers are currently accepted for credentials and dataclips. Decide which single API should remain, then confirm that the alternate resolver-passing path is removed and all affected calls use the same convention.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.