You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Has been observed very sporadically. Needs more experimentation to determine whether the underlying downlink properly gets closed, or if the lane simply contains the last value. Unfortunately this seems to be very hard to reproduce.
The JoinValueLanes that observed this behavior used String keys and Long keys, and pojo values whose Forms cast non-distinct Items to null -- if that happens to make a difference. When the issue happens, it can be observed both on the server side and on the client side:
Server side: after remove() is invoked and fails, iterate over the lane. The lane will still report null values under the keys, rather than the expected behavior of not revealing those keys in the first place.
Client side: downlinking to the lane reveals the keys present but without any corresponding values, e.g. using swim-cli might return @update(key:2313084330).
Note that for a given lane, it is possible that the first happens but not the second. I'm not sure whether the second can happen without the first.
It is a JoinValueLane.remove() problem because the following logic is present in a sample app:
@SwimLane("unsubscribe")
private CommandLane<String> unsubscribe = this.<String>commandLane()
.onCommand(uri -> {
this.statuses.remove(uri);
final String k = uri.substring("/submission/".length());
this.reviewed.remove(k);
this.answered.remove(k);
this.unanswered.remove(k);
this.unreviewed.remove(k);
});
where statuses is a JVL, and the remainder are MapLanes. The MapLanes always update correctly.
Has been observed very sporadically. Needs more experimentation to determine whether the underlying downlink properly gets closed, or if the lane simply contains the last value. Unfortunately this seems to be very hard to reproduce.
The JoinValueLanes that observed this behavior used
String
keys andLong
keys, andpojo
values whoseForms
cast non-distinctItems
tonull
-- if that happens to make a difference. When the issue happens, it can be observed both on the server side and on the client side:remove()
is invoked and fails, iterate over the lane. The lane will still reportnull
values under the keys, rather than the expected behavior of not revealing those keys in the first place.swim-cli
might return@update(key:2313084330)
.Note that for a given lane, it is possible that the first happens but not the second. I'm not sure whether the second can happen without the first.
It is a
JoinValueLane.remove()
problem because the following logic is present in a sample app:where
statuses
is a JVL, and the remainder are MapLanes. The MapLanes always update correctly.Possibly related to #107.
The text was updated successfully, but these errors were encountered: