Skip to content

[#374] Resolve "auto-cull stale channels"

aguestuser requested to merge 374-auto-cull-stale-channels into main

Closes #374 (closed) and implements the behavior specified in that card.

context

  • under heavy load (and absent a signald replacement), supporting lots of unused channels unnecessarily increases the memory footprint of each signald shard (specifically: each container uses ~2GB in RAM likely due to the size of the in-memory jackson keystore)
  • while we work to achieve a better persistence solution that would shrink this footrpint in signalc, we would like to mitigate the degredation to system performance caused by this situation
  • THIS MR: creates a daily job that automatically deletes all channels that haven't been used in over a month (using some of our existing work on recycle stale channels command to do this!
  • UPSHOT: this decreases system load and also protects our user's privacy by deleting unneeded metadata!

changes

refactor #requestToRecyle -> #requestToDestroy

  • call #destroy instead of #recycle for mature requests
  • modify logic (esp. notifications) to work for all possible code paths:
    • user-driven via execute
    • system-driven via jobs
    • maintainer-driven via routes
  • move to phoneNumberRegistrar.recycle module to phoneNumberRegistrar.destroy
  • also rename almost all instances of "recycle" -> "destroy"

add job to destroy stale channels every hour:

  • calls new func phoneNumberRegistrar#requestToDestroyStaleChannels, which:
    • uses new channelRepository#getStaleChannels func to retrieve all channels that have not been used in over 4 weeks (inferred by querying for joined messageCount s that were last updated before config.jobs.channelTtl, which is currently 4 weeks)
    • extracts the phone number from these stale channels and passes them to #requestToDestroy, which enques them for destruction if not used within next day

update cli commands:

  • boost destroy now enqueues destruction requests for N phone numbers
  • boost recycle no longer exists

tidbits / side effects:

  • prefix destruction config names with "channel" for clarity
  • replace "deactivate" with "destroy" in destruction warnings to create the necessary sense of urgency
  • rename config.job -> config.jobs (for consistency)
  • rename destructionRequestRepo#requestDestruction -> #findOrCreate
    • motivation: the old method name was redundant with (and thus easy to confuse with) phoneNumberRegistrar#requestDestruction

Merge request reports