* origin/la-contact-delete-fix:
t groups + contacts: make removes completely clean up state
contact-js: made channel handle onChannelError
contact-hook: tested it, got /synced path working, and subscriptions loading
contacts: fix group deletion and do some quality of life fixes
Signed-off-by: Jared Tobin <jared@tlon.io>
* liam-fitzgerald/lf/publish-del-edit:
chat-fe: move cancel button below comment edit
publish-js: lift editing state to comment list
publish: fix check on edit-comment delta
publish-js: avoid unnecessary scrollbars on note view
publish-js: allow deletion and editing of comments
publish: use @tas for comment ref in marks
Signed-off-by: Jared Tobin <jared@tlon.io>
When a group is left, the permissions no longer exist and the mailbox
subscription is kicked. Before attempting to resubscribe, we simply
check if we still have permissions and if not, leave the chat.
* origin/m/link-perf:
link-listen-hook: partially revert 05e6519
link fe: refactor message display into component
link fe: more informative "empty list" display
link-view: in pagination logic, only +lent once
link: minimal initial view result
link-view: add some hints to aid profiling
Signed-off-by: Jared Tobin <jared@tlon.io>
Previously, if filtering subscriptions turned up no results, nothing was
printed. With this change, we explicitly print "no matching subscriptions"
instead.
We weren't accounting for backlog subscriptions with non-zero message
indexes in their wires. Now, we look through all of our outgoing
subscriptions to identify relevant backlog subscriptions, and leave all
of those.
The more proper fix here is to not include message indexes in the wire
in the first place, since we don't ever reuse that anywhere. But that's
a more invasive change, so we just leave a TODO for it instead.
Previously, we were removing the relevant entry from the `synced` map
before calling `+pull-wire`, which requires an entry to still be there.
This lead to subscriptions not actually being pulled, commonly leading
to "subscribe wire not unique" errors on re-join.
In addition to fixing that, `%remove` actions now try to pull the
subscription regardless of whether they have an entry in the `synced`
map or not. `%leave` is always safe, and we might want to clean up
subscriptions that shouldn't be there anymore in the first place.
On initial load, instead of getting the first 25 links for every
collection, only get their totals and unread counts. This drastically
reduces the pageload time.
Updates the frontend to match:
- Handle initial results without link content.
- Dynamically load in collection's links, even for page 0.
Instead of auto-watching a new collection when it gets added to group
associations, require that the user explicitly choose to view it.
Of course, creation counts as opting in, so watch the collections we
create by default.
`at` is for when you expect an array of a certain exact structure. If it
has extra elements, that indicates you were mistaken about the strucutre,
so it should fail to match.
This commit pulls the spinner out of the header bar -- and
reincorporates it as a component that hooks into local state when
awaiting a new prop, or disabling an input.
RFC 2396 specifies that segments must be zero or more pchars.[1] We were
deviating from this by requiring at least one pchar per segment.
With this change, we support /some//path, and no longer lose the
trailing slash in /some/path/.
[1]: https://tools.ietf.org/html/rfc2396#section-3.3
In the wild, ships that were live pre-OS1 still had launch subscriptions
open to the clock on the /tile path, instead of the currently-used
/clocktile path. Additionally, launch state for the clock tile seemed
incomplete.
Here, we simply re-%add the clock to launch.
Note that launch currently does not clean up old subscriptions on
path change. For the pre-OS1 case, the old path is no longer in use,
rendering the subscription harmless. For cases where the correct
subscription was already in place, it'll print a %watch-wire-not-unique,
but doesn't do any harm besides that.
Previously, when the refresh-rate timer activated, and the thread from
the previous activation was still running, we would kill it and start
a new one. For low refresh rates, on slower machines, nodes, or network
connections, this could cause the update to never conclude.
Here we add a timeout-time to eth-watcher's config. If the refresh-rate
timer activates, and a thread exists, but hasn't been running for at
least the specified timeout-time yet, we simply take no action, and wait
for the next refresh timer.
Note that we opted for "at least timeout-time", instead of killing &
restarting directly after the specified timeout-time has passed, to
avoid having to handle an extra timer flow.
In the +on-load logic, we configure the timeout-time for existing
watchdogs as six times the refresh-rate. We want to set
azimuth-tracker's timeout-time to ~m30, and don't care much about other,
less-likely-to-be-active use cases of eth-watcher.
During the #2607 upgrade, strictly local collections got left out of the
listening set. (Because they did not have any outgoing subscriptions.)
This led to personal collections not being available on the frontend.
Here, we add upgrade logic for adding those back to our listening set again.
If a user had explicitly left a personal collection (instead of deleted it, for
whatever reason), they will have to leave it again. This case seems much more
rare than the "my collection is gone" one.
Events always pass through these, adding to the stack trace on-crash.
This information is practically never useful, however. Adding !. leaves
these cores out of the traces.
(Re)subscribing gets us a %contacts update, containing the full set of
contacts as it currently exists.
Previously, we would fully delete our local state, only to recreate it
using the data from the update.
Now, we never delete existing data, instead only creating if we don't
have it yet, and adding, removing or recreating contacts if they
changed.
In the future, we'll want an easy way to turn two contacts into an %edit
diff, to let us apply correct semantics to individual contacts, too.
Instead, %bundle and %add if we don't have the group locally yet,
or %add and %remove whatever the difference is between the local group
and the group as specified in the %path update.
In both, we make clear that the wire is always of the /@/group/^ form,
and alias the "group path" portion of the wire for clarity.
For kick, more obviously reuse the same wire, don't reconstruct it.
For watch-nack, only delete from the synced map if the source of the
watch-nack is still relevant. While we don't expect this to be relevant
considering current mode of operation, this does protect us against
strange cases.
Instead of going purely off metadata, we now track the collections we're
listening to, and allow the user to remove collections from that list.
This allows us to remove/ignore collections, without mutilating group
assocations locally.
We were taking care not to re-add something to our data store if we
already had it in there, but were still sending out an update
regardless.
With this, we only send out an update if we weren't previously aware
of the content.
Makes it so that |cancel %force skips the next thing in the queue if
you're not in the middle of something. If you are in the middle of
something, it skips the thing you're in the middle of (just like naked
|cancel).
This should resolve issues where |cancel doesn't drain the queue.
Considering some of the options here were atoms, not cells, $% wasn't
appropriate, and led to *etyp:abi:ethereum resulting in ford %ride execution
failure. Simply using $? instead would result in a fish-loop, so here we split
the atom cases from the tagged union ones with a $@.
Previously, the pretty-printing for %incoming and %outgoing results was hanging
on to and displaying irrelevant type information: "_list_ of subscriptions",
"wire with _head and tail_", and so on.
Here, we move to producing tangs, instead of vases, and print those. For the
%incoming and %outgoing cases, we print a line for every subscription, sorting
them by path and wire respectively, and giving clean, easily readable output.
If chats with identical resource paths were created, that would result
in chat-hook seeing updates twice.
These "/mailbox wire sub to local chat-store" subscriptions aren't
created by the current logic anymore, and as such any existing ones
should be eradicated.
* origin/m/chat-groupify-extra:
chat-view: %delete even without association
frontend: apply ec6c2ed69 to link, publish, groups
chat fe: clarify copy
chat fe: support adding chat to existing group
chat fe: invite search with/out ships
chat-view: allow %groupify into existing group
chat-view: add docs for %create action
Signed-off-by: Jared Tobin <jared@tlon.io>
When a ship breaches, we remove all messages that have yet to be
delivered to an app (eg if it's not yet started). We also add
|gall-sear to do this manually, but this shouldn't be needed in normal
operation.
Finally, to unblock ~zod and ~bus on mainnet, we sear one particular
ship automatically on loading hood. It cannot be done manually because
no userpace changes can be made until it's unblocked.
Previously, running %delete had a hard dependency on a (metadata-store)
association being present for the chat. If a remotely-hosted chat got
deleted, that would delete the association, preventing us from deleting
the chat for ourselves.
Now, we simply neglect to do related metadata deletions if no
association was present in the first place.
In many cases running without %force is insufficient because ford
crashes while unsubscribing. This should fix some cases of OTAs being
received but not processed.
We have three stacks: the hoon stack, bar stack, and duct stack. This
turns the bar stack to a list of ducts and adds it to the hoon stack.
This tells you the ducts of the moves that caused the move where you
crashed.
See:
recover: dig: intr
crud: %belt event failed
bail: intr
bar-stack
~[
~[/g/use/spider/~zod/build/~.dojo_0v5ogno.5anji.vn3f6.4gs7t.6r2ft /d //term/1]
~[/d //term/1]
~[/g/use/spider/~zod/find/~.dojo_0v5ogno.5anji.vn3f6.4gs7t.6r2ft /d //term/1]
~[/g/use/dojo/~zod/out/~zod/spider/drum/wool /d //term/1]
~[/d //term/1]
~[/g/use/dojo/~zod/drum/hand /d //term/1]
~[/g/use/hood/~zod/out/~zod/dojo/drum/phat/~zod/dojo /d //term/1]
~[/d //term/1]
~[//term/1]
]
call: failed
/~zod/home/~2020.3.17..23.14.11..50e0/sys/vane/ford:<[6.128 3].[6.220 5]>
/~zod/home/~2020.3.17..23.14.11..50e0/sys/vane/ford:<[6.129 3].[6.220 5]>
/~zod/home/~2020.3.17..23.14.11..50e0/sys/vane/ford:<[6.132 3].[6.220 5]>
...
Gives you a poor man's progress bar. For example, to determine how much
of an OTA you've downloaded from your sponsor, run:
|ames-sift (sein:title our now our)
|ames-verb %rcv
and then to turn it off:
|ames-verb
Downgrades unmanaged chat paths to their uglified versions, as used by
web chat. Removes "group-based" indicators and makes them implicit in
shorter paths instead.
Under mysterious conditions, chat-cli might get into a state where its
rendering width is set to zero. This makes sure we set it back to 80
if that's the case.
This commit is mostly just precaution.
This reverts commit 046506f9d4, reversing
changes made to 6ef08962ef.
I'm reverting this as we're moving to a new branch/release model in
which breaching changes (as this one is) will live on a long-running
'next' branch, rather than alongside non-breaching changes in master.
This revert should itself be reverted on the 'next' branch.
It was filling the number.envelope prior to adding the envelope to the
mailbox, but wasn't actually including that change in the %message(s)
update that was getting sent out.
This makes +append-envelope return both the updated mailbox _and_ the
modified envelope, which we then use in our outgoing update.
During upgrade, we gassed _in_ a map, instead of _by_, causing it to use
set-style sorting, leading to incorrect lookups.
This fixes that upgrade logic, and re-builds the map for existing instances.
+dbug [%state 'some-hoon'] now allows you to run some-hoon against the
application's state. That hoon has access to the bowl and stdlib for
more dbugging convenience.
Was using "manual" scries, and incorrect ones at that. Would crash, causing
subscriptions to not go through. Now uses the helper function and correct paths.
Re-enables chat creation, touches up invite logic, and makes everything
work with the new "un/managed" attribute of chats.
Changes the +target type, so requires state transition. We use that
opportunity to clean up our messages mirror (memory reclamation).
"Unmanaged" chats should work the same as they did before.
Group-based chats are secondary citizens, but supported by prepending
"group " to whatever target you want to use. ie:
;join group ~marzod/secret-club :: join a group-based chat
;group ~marzod/secret-club :: target a group-based chat
The latter case should be rarely needed, as glyphs remember this
attribute of their bound target.
Creating a group alongside a chat is supported through:
;create village-with-group /cool-kids
You can then invite to that group (and by extension the associated chat)
by doing:
;invite group /cool-kids ~rinsed-walrus
To 30 blocks + 30 blocks + 0-5 minutes == about 15 minutes total.
Further reduction should be possible, but requires changing the
algorithm a bit. We don't want to reduce the number of confirmations
below about 30, though, since we don't handle reorganizations well.
See #2414.
