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

Transaction service accepts requests without parties and returns an empty stream #1250

Closed
stefanobaghino-da opened this issue May 20, 2019 · 5 comments

Comments

Projects
None yet
4 participants
@stefanobaghino-da
Copy link
Member

commented May 20, 2019

The transaction service currently accepts a SubmitRequest with a filter with an empty set of parties and returns an empty stream. Probably a better approach would be requiring at least one party to be there to subscribe to and return an error if it's not there, rather than opening (and possibly keeping it that way) an empty stream. This would ensure that the user gets an immediate feedback, rather than (possibly mistakenly) subscribing to a feed that will always be empty.

Another possible approach could be changing the semantics of an empty set of parties to mean "subscribe to all transactions over which I have visibility", but I'm not sure this would be desirable.

@bitonic

This comment has been minimized.

Copy link
Contributor

commented May 20, 2019

I'd be OK with this, @gaboraranyossy-da and @gerolf-da should weigh in.

@gerolf-da

This comment has been minimized.

Copy link
Contributor

commented May 20, 2019

Sure, as of right now, there is no situation where a request with no party filter would ever return any data. Question is whether we want to reject the request with BAD_REQUEST (my preferred method) or simply respond with an empty stream that is also closed (yet again slightly surprising behavior).

@gaboraranyossy-da

This comment has been minimized.

Copy link
Contributor

commented May 20, 2019

I vote for BAD_REQUEST

@stefanobaghino-da

This comment has been minimized.

Copy link
Member Author

commented May 20, 2019

BAD_REQUEST it is then, a PR is coming soon, thanks for the input. 🙏

@stefanobaghino-da

This comment has been minimized.

Copy link
Member Author

commented May 20, 2019

I don't see a BAD_REQUEST, maybe you were referring to this? Seems apt.

    /**
     * Client specified an invalid argument.  Note that this differs
     * from FAILED_PRECONDITION.  INVALID_ARGUMENT indicates arguments
     * that are problematic regardless of the state of the system
     * (e.g., a malformed file name).
     */
    INVALID_ARGUMENT(3),

stefanobaghino-da added a commit that referenced this issue May 20, 2019

Reject transaction filters without any party
Fixes #1250

The previous behavior when receiving a transaction filter without any
party was to reply with an empty stream. Since, given the current
situation, no data could ever be served for such request, it represents
a better feedback for the user to reject such requests as carrying an
`INVALID_ARGUMENT`.

cocreature pushed a commit that referenced this issue May 21, 2019

Reject transaction filters without any party
Fixes #1250

The previous behavior when receiving a transaction filter without any
party was to reply with an empty stream. Since, given the current
situation, no data could ever be served for such request, it represents
a better feedback for the user to reject such requests as carrying an
`INVALID_ARGUMENT`.

cocreature pushed a commit that referenced this issue May 21, 2019

Reject transaction filters without any party
Fixes #1250

The previous behavior when receiving a transaction filter without any
party was to reply with an empty stream. Since, given the current
situation, no data could ever be served for such request, it represents
a better feedback for the user to reject such requests as carrying an
`INVALID_ARGUMENT`.

stefanobaghino-da added a commit that referenced this issue May 21, 2019

Reject transaction filters without any party (#1257)
Fixes #1250

The previous behavior when receiving a transaction filter without any
party was to reply with an empty stream. Since, given the current
situation, no data could ever be served for such request, it represents
a better feedback for the user to reject such requests as carrying an
`INVALID_ARGUMENT`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.