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

Clarify handling of malformed context objects by Desktop Agents #872

Closed
Tracked by #916
kriswest opened this issue Dec 2, 2022 · 1 comment · Fixed by #972
Closed
Tracked by #916

Clarify handling of malformed context objects by Desktop Agents #872

kriswest opened this issue Dec 2, 2022 · 1 comment · Fixed by #972
Assignees
Labels
api FDC3 API Working Group docs Documentation
Milestone

Comments

@kriswest
Copy link
Contributor

kriswest commented Dec 2, 2022

Area of Issue

[x] API

Issue Description:

The Desktop Agent API definitions in TypeScript specify that its functions accept Context objects (at their simplest, JSON/Javascript Objects that have a type field). However, the Standard does not specify how they should respond if passed a malformed Context (i.e. one that is not an Object or one that lacks a type field).

Generally, other error responses are defined already and functions are restricted to returning Javascript (or platform-appropriate) Error objects with messages drawn from a specific error enumeration, e.g.:

fdc3.open:

If an error occurs while opening the app, the promise MUST be rejected with an Error Object with a message chosen from the OpenError enumeration.

fdc3.raiseIntent

The Desktop Agent MUST reject the issuing app's promise, with a string from the ResultError enumeration, if: (1) the intent handling function's returned promise rejects, (2) the intent handling function doesn't return a promise, or (3) the returned promise resolves to an invalid type.

Due to this lack of defined behaviour, it is not currently possible to test Desktop Agents for consistent behaviour. Hence, test cases related to this (that currently exist in the conformance framework) also need to be removed.

Future versions of the FDC3 Standard should specify how malformed Context Objects should be handled and (where necessary) define error messages that should be returned.

@kriswest
Copy link
Contributor Author

kriswest commented Dec 2, 2022

We should probably define an error to be returned by all of fdc3.broadcast, channel.broadcast, fdc3.open, fdc3.raiseIntent, fdc3.raiseIntentForContext, fdc3.findIntent, fdc3.findIntentByContext. Doing so will ensure that the developer/app submitting the malformed context is informed of the error. I don't think we need to do anything on the receiving end (fdc3.addContextListener etc.) is malformed context is not submittable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api FDC3 API Working Group docs Documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant