Skip to content

Say why a presence write was refused #736

Closed

Description

@josephfusco

wp_set_presence() returns false when recording is off, the table is missing, $date_gmt is malformed, $expires_in is unusable, or the query fails. A caller can't tell which, so it can't tell "this site doesn't record presence" from "something broke".

Return a WP_Error with its own code for each.

To decide

Callers today check false. Either:

  • A $wp_error flag, like wp_insert_post(): false stays the default and true gets the WP_Error. Nothing breaks.
  • Always a WP_Error, and callers switch to is_wp_error(). Cleaner, but every false === wp_set_presence( … ) check breaks, including gutenberg-sync-engines'.

The $wp_error flag fits naturally into the $args array if that lands first.

Tasks

  • Pick one
  • One error code per rejection, listed in the docblock and README
  • Same for wp_presence_exchange()
  • Tests: each rejection returns its own code

Part of #676.

Activity

  1. added
    [Type] EnhancementA suggestion for improvement of an existing feature
    Public APIAdds a hook, route, constant, or global that third parties can depend on
    Needs DecisionBlocked on a maintainer call, not on more work
    on Oct 5, 2026
  2. added this to the Future Release milestone on Oct 5, 2026
  3. huzaifaalmesbah commented on Oct 8, 2026

    @huzaifaalmesbah
    Member

    I'd go with the $wp_error flag, defaulting to false, like wp_insert_post().

    Always returning WP_Error would break callers quietly, not loudly: a WP_Error is truthy, so every if ( ! wp_set_presence( … ) ) here (REST, WP-CLI, wp_presence_exchange()) and in gutenberg-sync-engines would read a refusal as success, and a storage class returning it from Gutenberg's WP_Sync_Storage::set_awareness_state(): bool would throw a TypeError. Gutenberg's own sync server keeps storage returning bool and builds the WP_Error at its REST boundary, so the same split fits here.

    The REST controller and WP-CLI already check recording (501) and the table (503) before writing, so the generic rest_presence_failed 500 is left for a failed database write; the flag's job is mainly for callers outside this plugin, which today can't tell those apart.

    #792 is a draft of this. Once #789 lands I'll rebase it so the flag is only a 'wp_error' key in $args. Happy to take it if you assign me.

  4. josephfusco commented on Oct 8, 2026

    @josephfusco
    CollaboratorAuthor

    Decided: the $wp_error flag, as a 'wp_error' key in $args that defaults to false, for the reasons you gave; with it on, wp_presence_exchange() returns the WP_Error in place of the room when its write is refused. #789 is merged, so #792 is ready to rebase that way, and if it lands before the 0.17.0 release (#790) it ships together with $args. Thanks for the careful write-up!

  5. added a commit that references this issue on Oct 8, 2026
    1058be7
  6. added a commit that references this issue on Oct 9, 2026
    fbca40d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Public APIAdds a hook, route, constant, or global that third parties can depend on[Area] DatabaseIssues for the wp_presence table and cron cleanup[Type] EnhancementA suggestion for improvement of an existing feature

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions