Skip to content

[#338] Resolve "maintainers can restart signalboost w/ signal message + password"

aguestuser requested to merge 338-maintainers-can-restart-signald-with-signal-message into main

Closes #338 (closed)

context

  • when signald crashes a channel's thread, the easiest way to repair the situation is to restart signalboost
  • sometimes this happens on a weekend when we are not at a laptop
  • so: this MR introduces a flow that allows SB maintainers to restart signalboost from their phone by sending a command and passphrase to the diagnostics channel

changes

  • run against forked signald build with a new abort command (only exists in sb fork):

  • add 2 helpers to signal module for use in the restart flow:

    • signal#abort: sends a poison pill message to signald, causing it to shutdown
    • signal#isAlive
      • issues version request to signald
      • resolves with version if response received or reject if request times out

  • implement execute#maybeRestart:

    • triggered by receiving BOOST RESTART <PASSPHRASE> on any channel
    • authentication flow blocks restart and sends error response if:
      • command sender is not maintainer
      • command is not issued over diagnostics channel (new restriction)
      • passphrase is wrong
    • if authentication works, proceed with restart:
      • send poison pill to abort signald, leveraging on restart:always directive in docker-compose to ensure that it restarts after aborting
      • use application module's stop and start methods to restart signalboost with a wait directive to ensure signald is running in time for app.run's subscribe calls to work
      • make call to signal.isAlive before returning to ensure that signald is in fact up
    • if restart worked, send a (localized!) notification of restart success to all maintainers on diagnostics channel

side-effects

  • refine localization lgoci in execute specs:

    • goal: fix some errant translation logic, introduce more rigorous approach to testing localization in execute module via randomizing language of incoming commands and all channel members
    • fix:
      • provide a new localizedCmd lookup table (that provides commands in a random language every test suite run)
      • generate admins/members with randomized language memberships for every run and some helpers to access notifications in their language
    • use results of these tests to fix:
      • business logic errors in which:
        • several notifications were mistakenly being sent in the sender language rather than the recipient language
        • french ADD results were returning functions instead of strings
      • testing errors/omissions in which we:
        • asserted that messages were sent in a channel.language (when there is no such thing: language is a field on memberships, not channels)
        • failed to distinguish between cases in which notifications are sent in a sender/recipient's language or the language in which the incoming command was sent
        • asserted presence of (vestigal) command responses instead of parse errors for invalid phone numbers
        • failed to provide unit test for parse errors for invalid REPLY payloads (which were the subject of prolonged deliberation in last delivery cycle)

  • modify all docker containers in all docker-compose files to use restart: always

  • add stdout/stderr logging to util.exec

  • clean up socket/index

    • inline destroySocketConnection 1-liner
    • make it possible to run socket pool after stopping it

  • provide default credentials for twilio client

    • the twilio client singleton is loaded at import time (maybe we should fix that?)
    • and it now throws if valid sid and token aren't provided to constructor
    • as workaround, provide them in test configs
Edited by aguestuser

Merge request reports