-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lido offchain plugins p1 #435
Conversation
🦋 Changeset detectedLatest commit: 7e96332 The changes in this PR will be included in the next version bump. This PR includes changesets to release 15 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Current dependencies on/for this PR: This comment was auto-generated by Graphite. |
|
||
// add a plugin promise to await, resolves to unwraps, refunds, and actions to enqueue | ||
// returns `this` so it's chainable | ||
pluginFn(pluginPromise: Promise<PluginFnResult>): this; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can probably have a better name than pluginFn
- instead, how about enqueueAsyncPlugin
or something like that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well the its not the plugin itself that's being called, a function on the plugin (plugins will have multiple methods). Think this is probably fine. Fn or call but same thing
@@ -5,10 +5,13 @@ import { Action, Address, Asset, OperationMetadata } from "../primitives"; | |||
const ONE_DAY_SECONDS = 24 * 60 * 60; | |||
|
|||
// A joinsplit request is an unwrapRequest plus an optional payment | |||
export interface JoinSplitRequest { | |||
export interface JoinSplitRequest extends UnwrapRequest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kinda nit, but this type is effectively saying a JoinSplitRequest
is a special case of UnwrapRequest
, when we really want the opposite semantics - UnwrapRequest
is a special case of JoinSplitRequest
.
We can get the latter semantics via the following:
export interface JoinSplitRequest {
asset: Asset;
unwrapValue: unwrapValue;
payment?: ConfidentialPayment;
}
export type UnwrapRequest = Omit<JoinSplitRequest, "payment">;
Here, a JoinSplitRequest
is not assignable to a variable of type UnwrapRequest
, but an UnwrapRequest
is assignable to a variable of type JoinSplitRequest
|
||
### Unreleased | ||
|
||
- Package name migrated from `sdk` to `core` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clear changelog entries from core/sdk
...inner, | ||
use: use, | ||
convertWethToWsteth(amount: bigint) { | ||
const prom = new Promise<PluginFnResult>((resolve) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically don't need to enqueue a promise here, as there's no async.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well its for type consistency since we want all plugins to add to same array and have same interface to live by (enqueue actions, unwraps, refunds for op request builder to handle at .build()). Other option is to just push directly to array but would rather keep devX consistent across plugins
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is not what the ERC20 plugin is doing - in this case we should force it to enqueue a promise as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait but it is enqueuing promise, its same pattern as wsteth adapter plugin
https://github.com/nocturne-xyz/monorepo/pull/435/files#diff-4adf8b51946131cc888242ac38ca0ada71088ac788898b52540479972ab48382R84
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh oops I see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we also make the "base" methods all enqueue promises as well then? Someone could do something like:
await builder
.use(Erc20Plugin)
.transfer(...) // async
.unwrap(...) // sync
.build()
in .build()
, the unwrap()
will be applied before, not after the transfer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I can do this for consistency
use: use, | ||
convertWethToWsteth(amount: bigint) { | ||
const prom = new Promise<PluginFnResult>((resolve) => { | ||
const chainId = this._op.chainId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we might need to be careful how this
gets bound in the closure. It could very well be that if you call use
after calling convertWethToWsteth
here, the this
inside the closure could be pointing to the pre-extension builder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure I'm understanding, what might happen here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suppose user does something like:
builder
.use(Erc20Plugin)
.transfer(...)
.use(SomeOtherPlugin)
.someOtherPluginMethod(...);
when .transfer(...)
is called, it'll create a closure over a context where this
points to the builder object returned by .use(Erc20Plugin)
and pass it into the promise constructor. Then the second call to .use(SomeOtherPlugin)
is gonna return a new object with all of the methods / properties copied over, but the context closed over by the closure created during transfer(...)
will still have this
pointing to the object returned by .use(Erc20Plugin)
.
This isn't really an issue to fix as much as it is something I wanted to flag that I noticed just now - this might be a problem with the current synchronous implementation (honestly not sure how "object methods" get their this
bound when they're copied to another object), but it's definitely a problem here depending on whether shallow or deep copies are being made (and it's not immediately clear to me which is the case, it may actually depend on the properties / plugins involved)
090e0e9
to
7448898
Compare
…in op req builder is consistent with actual
…e at build() step
7448898
to
7c69b6f
Compare
Motivation
Start offchain work needed to support Lido. OpRequestBuilder.build() needed to be async due to plugins like Uniswap needing to make network calls for fetching routes.
Solution
Proof
https://www.loom.com/share/6e5d5094613247788783baedf0e16b63?sid=b4ade8b1-a86c-4613-99f0-f38bad62b579
PR Checklist