Bullet-proof state management and reload events in ClientCommChannel.

Review Request #13336 — Created Oct. 12, 2023 and submitted

Information

Review Board
release-6.x

Reviewers

Two issues were found while debugging a strange issue encountered
locally with ClientCommChannel. When performing JavaScript test runs,
I was getting page stalls, with the dev server showing constant reloads
for other Review Board tabs. This was happening despite the fact that
the JavaScript tests should not be sending anything over a channel, and
the other pages should have ignored any such messages anyway.

Despite not finding the cause of that problem, two other issues were
found.

First, the unit tests were attempting to reset the static
ClientCommChannel.instance property after tests ran. This had two
problems:

  1. We never actually closed the BroadcastChannel, leading to a leak
    that could cause events to be processed on the page.

  2. When setting a static property of a Spina-wrapped class, we actually
    end up setting it on the wrapper and not the wrapped class. We'll
    need to think through this a bit, but for now, the rule is that only
    a class is able to manage its own static attributes.

A new ClientCommChannel.close() method has been added that takes care
of both problems.

Second, in theory, a reload message on a ClientCommChannel with a
null payload could cause Review Board pages aside from review request
pages to reload unnecessarily.

Reload handling uses page-specific data to determine if a reload request
from another tab applies to the current page. For review request pages,
this used the review request ID, which was generally fine since no other
pages sent this command over. However, if the command were to be issued
on any other page, resulting in null reload data, then all non-review
request pages would attempt a reload.

We now disallow any reload attempts if there's no page data to key
checks off of. This applies to both sending the reload message and
processing them, as a safety mechanism.

Unit tests pass, and the asserts weren't hit. Previously, adding asserts
around instance management showed that the instance could not be
reset.

Verified that no other Review Board pages were being activated when
force-sending a broadcast message with null page data, and that normally
sending this resulted in an error log.

Summary ID
Bullet-proof state management and reload events in ClientCommChannel.
Two issues were found while debugging a strange issue encountered locally with `ClientCommChannel`. When performing JavaScript test runs, I was getting page stalls, with the dev server showing constant reloads for other Review Board tabs. This was happening despite the fact that the JavaScript tests should not be sending anything over a channel, and the other pages should have ignored any such messages anyway. Despite not finding the cause of that problem, two other issues were found. First, the unit tests were attempting to reset the static `ClientCommChannel.instance` property after tests ran. This had two problems: 1. We never actually closed the `BroadcastChannel`, leading to a leak that could cause events to be processed on the page. 2. When setting a static property of a Spina-wrapped class, we actually end up setting it on the wrapper and not the wrapped class. We'll need to think through this a bit, but for now, the rule is that only a class is able to manage its own static attributes. A new `ClientCommChannel.close()` method has been added that takes care of both problems. Second, in theory, a reload message on a `ClientCommChannel` with a `null` payload could cause Review Board pages aside from review request pages to reload unnecessarily. Reload handling uses page-specific data to determine if a reload request from another tab applies to the current page. For review request pages, this used the review request ID, which was generally fine since no other pages sent this command over. However, if the command were to be issued on any other page, resulting in `null` reload data, then all non-review request pages would attempt a reload. We now disallow any reload attempts if there's no page data to key checks off of. This applies to both sending the reload message and processing them, as a safety mechanism.
cbda84eb177fac1821fead31125e4daae1b65409
maubin
  1. Ship It!
  2. 
      
chipx86
david
  1. Ship It!
  2. 
      
chipx86
Review request changed
Status:
Completed
Change Summary:
Pushed to release-6.x (a68a721)