Skip to content
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

Proposal: Generic subscription options while adding contract listener #1396

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

niklas-emmelius-mittelstand-ai

Generic subscription options while adding contract listener

Generic options for the automatically generated subscription can be passed in listener options

{
  "name": "PayPerUseListener",
  "options": {
    "firstEvent": "newest",
    "subscriptionOptions": {
      "additionalOption1": "option1",
      "additionalOption2": "option 2"
    }
  },
  "topic": "default1"
}

Intention

A privacyGroupId could be passed to Ethconnect and calls to priv_getLogs etc. would be possible.
Every plugin would be able to listen for the subscriptionOptions necessary for its subscription configuration.

The introduced changes do not break existing functionality.

- Options can be used to pass options for automatically created subscription

Signed-off-by: Niklas Emmelius <niklas.emmelius@mittelstand.ai>
Signed-off-by: Niklas Emmelius <niklas.emmelius@mittelstand.ai>
@nguyer
Copy link
Contributor

nguyer commented Sep 12, 2023

Thanks for opening this! This seems like an interesting idea and I or one of other maintainers will review this and provide some feedback as soon as we can, though most of them are a bit busier than usual at the moment.

@nguyer
Copy link
Contributor

nguyer commented Sep 14, 2023

Ah, it looks like the linter is complaining because a file was updated by the copyright year in the header wasn't also updated. Sorry, it's a silly linter rule.

Error: pkg/core/contract_listener.go:1:17: Expected:2023, Actual: 2022 Kaleido, Inc. (goheader)

@@ -44,7 +44,8 @@ type ContractListenerWithStatus struct {
Status interface{} `ffstruct:"ContractListenerWithStatus" json:"status,omitempty" ffexcludeinput:"true"`
}
type ContractListenerOptions struct {
FirstEvent string `ffstruct:"ContractListenerOptions" json:"firstEvent,omitempty"`
FirstEvent string `ffstruct:"ContractListenerOptions" json:"firstEvent,omitempty"`
SubscriptionOptions *fftypes.JSONAny `ffstruct:"ContractListenerOptions" json:"subscriptionOptions,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm struggling with what this field should be named. For context, in the older ETHConnect codebase we used to call these "subscriptions". In the newer FFTM API (which EVMConnect is based on), we now refer to these as "listeners" to help distinguish them from FireFly Subscriptions (which are a higher level object). So this field actually ends up maping to Listener.Options
https://github.com/hyperledger/firefly-transaction-manager/blob/fe5ace887c9f541c3053fd31d937d46ce6adc3c9/pkg/apitypes/api_types.go#L212

But calling this field ContractListenerOptions.ListenerOptions seems a bit redundant 🤔

@awrichar or @peterbroadhurst Do you have any suggestions here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nguyer - sorry I missed this before.

I think the consistent pattern here with other things, would be that the options are passed through to EVMConnect. If you look at invoke APIs, or the tokens - that's what we do I believe.

@nguyer
Copy link
Contributor

nguyer commented Jan 17, 2024

Closing and re-opening to get the build to run again

@nguyer nguyer closed this Jan 17, 2024
@nguyer nguyer reopened this Jan 17, 2024
@nguyer
Copy link
Contributor

nguyer commented Feb 15, 2024

@niklas-emmelius-mittelstand-ai Sorry it took so long to get feedback on this one. If you want to rename SubscriptionOptions to ListenerOptions I'm happy to merge this PR. Thanks!

Copy link
Contributor

@nguyer nguyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll also want to run make locally to make sure the build is passing. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants