[v0.3] Specify behavior for fields#delete, fields#get-and-delete with invalid field name

Open
#783 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Domain
api, documentation

Research direction

Start with the specified delete and get-and-delete definitions in the issue, then compare their invalid-name behavior with get() and the behavior currently returned by Wasmtime. Resolve whether delete silently succeeds or returns invalid-syntax, and whether get-and-delete propagates the corresponding error, then update the WASI specification and any affected conformance coverage.

Written by the indexing model from the issue text.

Description

P-http

Consider:

    /// Delete all values for a name. Does nothing if no values for the name
    /// exist.
    ///
    /// Fails with `header-error.immutable` if the `fields` are immutable.
    delete: func(name: field-name) -> result<_, header-error>;
    /// Delete all values for a name. Does nothing if no values for the name
    /// exist.
    ///
    /// Returns all values previously corresponding to the name, if any.
    ///
    /// Fails with `header-error.immutable` if the `fields` are immutable.
    get-and-delete: func(name: field-name) -> result<list<field-value>, header-error>;

When passed an invalid field name, delete could silently succeed (like get does), because by definition there is no field with that name; the operation will not set any field of the fields object. Or it could return an invalid-syntax error, because it has the Result. Wasmtime currently returns an error.

Similar concerns for get-and-delete; I guess it should be specified as propagating any error, as if get() then delete().

Dominant language
Rust
Stars
5.8k
Forks
333
Avg merge
2d 13h
Merged PRs (30d)
3

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from WebAssembly/WASI

All issues in WebAssembly/WASI

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.