This was broken by the recent nip19 changes, let's fix it again
Fixes: cb4adf06f1 ("nip19: added swift enums")
Changelog-Fixed: Fix nostrscripts not loading
Signed-off-by: William Casarin <jb55@jb55.com>
otherwise there is contention and tends to crash
Fixes: f06b882139 ("purple: consolidate UserBadgeInfo with Account")
Changelog-Fixed: Fix crash when accessing cached purple accounts
Signed-off-by: William Casarin <jb55@jb55.com>
Also doing this so I can add a changelog entry
Changelog-Changed: Disable inline text suggestions on 17.0 as they interfere with mention generation
Signed-off-by: William Casarin <jb55@jb55.com>
Rename get_account to fetch_account to make it clear that it is always a
call to the server.
Add get_maybe_cached_account method that checks cached before calling
fetch_account.
Signed-off-by: William Casarin <jb55@jb55.com>
This fixes subtle bugs with transaction inheritence. Since we were not
passing the inherited state to moved value, we were sometimes committing
transactions more than once.
Changelog-Fixed: Fix many nostrdb transaction related crashes
This is a potential fix for some of the crash reports that have been
streaming in. They all seem to be crashing within ndb_close_txn. I
suspect this means that the transactions are trying to get closed when
ndb is already closed. Closing Ndb will close the transactions
automatically, so it looks like we might be trying to close twice.
This was causing crashing and corruption issues. This should have been
handled by the garbage collector, but for some reason old references
still hang around.
Add a "close" method to DamusState which disconnects from relays and
closes nostrdb.
Changelog-Fixed: Fix crash when logging out and switching accounts
Changelog-Fixed: Fix persistent local notifications even after logout
Signed-off-by: William Casarin <jb55@jb55.com>
It's never safe to return an unsafeUnownedValue
Fixes: c4f0e833ff ("Reuse local notification logic with push notifications")
Cc: Daniel DAquino <daniel@daquino.me>
Signed-off-by: William Casarin <jb55@jb55.com>
Since there may be situations where we close and re-open the database,
we need to make sure transactions fail when the database is not open.
Make NdbTxn an init?() constructor and check for ndb.closed. If it's
closed, then fail transaction construction.
This fixes crashes during high database activity when switching from
background to foreground and vice-versa.
Fixes: da2bdad18d ("nostrdb: close database when backgrounded")
I realized we didn't have this in the contributor docs. Noone will read
it, but at least we'll have something to point to for future contributors.
Cc: kernelkind <kernelkind@gmail.com>
Signed-off-by: William Casarin <jb55@jb55.com>
Otherwise iOS gets mad because we are holding onto a lockfile in a
shared container which is apparently not allowed.
Fixes: a1e6be214e ("Migrate NostrDB files to shared app group file container")
When you are searching for results, don't wipe the current result set if
there are some previous results and the current query is returning 0
results. This is pretty common when you start typing, it's weird for the
results to randomly clear when looking for stuff.
I'm noticing duplicate notes in the database, which might happen when
the ingester and writer get spammed with the same note rapidly. Add a
sanity check during the write so that we only ever write a note once.
Fixes: 1cf898e0b2 ("ndb: update nostrdb")
Changelog-Fixed: Fix duplicate notes getting written to nostrdb
Signed-off-by: William Casarin <jb55@jb55.com>
Many different parts of the codebase could be opening transactions when
somewhere higher in the heirarchy on the main thread might already have
an active transaction. This can lead to failed transaction opening which
is bad.
Instead of relying on passing down the transaction to subviews, lets
keep track of the active transactions in a thread-local dictionary. That
way whenever we create a new transaction we can inherit the one that is
already active in the current thread.
Inherited transactions don't end the query when they are garbage
collected, we still expect the first-opened query to do this.
Due to the way the range queries work for newest-first searches, we can
have a situation where the MDB_SET_RANGE gets placed on either the
correct place or just after the correct place. To position the cursor
correctly, we jump back one if the search result prefix doesn't match.
Signed-off-by: William Casarin <jb55@jb55.com>
William Casarin