search

tahoe-lafs / magic-folder

Tahoe-LAFS-based file synchronization
Other
25 stars 7 forks source link

the "read-only" option for `..../join` needs documentation, and shouldn't be required #748

Closed crwood closed 6 months ago

crwood commented 7 months ago

As of Magic-Folder version 24.1.0, attempting to "join" an invite (via a web API POST to /experimental/<folder>/join with JSON body containing currently-documented keys/values) returns a 400 HTTP error with a body of '{"reason": "Extra keys: read-only"}'.

Upon looking at the higher-level MagicFolderClient.join code, I notice that a "read-only" key is now always being passed to "join" CLI calls. It is unclear to me, however, whether this option is actually supposed to be required (since it does not appear to be documented?). Nevertheless, if I include a "read-only" key in the JSON body of my POST (with a value of None or False), I'm able to successfully complete the invite via the web API.

If the read-only key is supposed to be required, consider updating the error message accordingly (e.g., to "Missing key(s)..." instead of "Extra keys..."). If, on the other hand, read-only is intended to be optional, the error message above seems the result of a bug somewhere. In any case, it would be useful if the intended usage of the option (including it's expected behavior and possible values) was documented alongside the others in docs/invites.rst.

Note that this issue is not present in the previous version of Magic-Folder (23.6.0).

meejah commented 7 months ago

"read-only" is intended to be optional, as per its docstring -- which I guess would have been more obvious if there was docs written I guess :/

meejah commented 6 months ago

(Attempting to make some tests fail ... but not yet; see branch)

meejah commented 6 months ago

Okay, got a failure .. cli-parsing was sending it as "0" when not specified :/