cwebber has quit [Remote host closed the connection]
cwebber has joined #sandstorm
<kentonv>
isd, this is weird, etherpad seems to be working fine for me?
<ocdtrekkie>
It worked for me on a test on Alpha but not on my own server.
<ocdtrekkie>
It was also a but intermittent.
<kentonv>
hmm, it works for me on both alpha and my sandcats server
<kentonv>
is everyone using the latest version of etherpad?
<ocdtrekkie>
Try reopening a grain you just opened.
<ocdtrekkie>
I think it might occur when multiple accesses are made to the grain/the grain is accessed again before shutdown.
<kentonv>
still works
<ocdtrekkie>
Odd. But Ian and I both reproduced it independently on our servers, and Ian says reverting fixed it.
<kentonv>
ok I think I can see where the problem would arise, there was actually a bug *fix* in Cap'n Proto recently but the apps would all still be using the broken version...
<kentonv>
it must be highly timing-dependent
<ocdtrekkie>
So redeploying Etherpad with current capnp would fix it as-is? But is there a capnp fix to make this issue not appear?
<kentonv>
we'd have to redeploy all apps that were built since Sandstorm started using `-> stream` in capnp schemas. :/
<kentonv>
I'm building the rollback now
<ocdtrekkie>
I'm guessing that was a while ago.
<kentonv>
yeah, 2020-06-24
<ocdtrekkie>
22 apps. Many of which we control distribution for, but definitely some we don't.
<ocdtrekkie>
Namely probably Wekan, Monica, Davros, Baby Buddy, and having to monkeypatch ShareLatex again.
<kentonv>
yeah I'm going to need to find a work-around
<kentonv>
we actually hit the same problem in Workers but solved it by a three-step deployment -- fix the bug, roll that out globally, then apply the optimizations that the bug interacts badly with. But that's not really a viable solution for Sandstorm.
<kentonv>
new release is out (actually, was out a couple hours ago)
<isd>
Whatever I do, I should make a point of trying to make the haskell stuff compatible
xet7 has joined #sandstorm
<fr33domlover>
Interesting
<fr33domlover>
isd: What do you think about Persistent.save() versus having all capabilities be persistent built-in? Without needing to implement any interface, each ocap coming with a sturdyref
<fr33domlover>
e.g. 'export' automatically producing a sturdyref for the new ocap
<fr33domlover>
getSturdyRef :: Client a -> SturdyRef
<isd>
How would that work?
<isd>
In the general case, this should work for processes that have actually shut down and been restarted. So to make that happen you'd have to be able to serialize arbitrary values from Haskell too
<isd>
We could maybe make something that works for anything that has an instance of Generic
<isd>
The thing with using Generic or such vs. an actual capnp schema is that there's no built in answer to evolving the schema for a haskell datatype
<isd>
So if you want to add a field or something you need to figure out what to do with old data.
<isd>
This is kindof the nice thing about capnp; it's got an answer to that built-in
<isd>
But it would still be nice to be able to just serialize a misc. haskell datatype
<fr33domlover>
isd: I was thinking it'd be useful to persist through network reconnections, even if not persisting process restart? But yeah, built-in serialization would be great. Perhaps using some typeclass? Where you map values to some Value type (e.g. a bit like aeson's Value or persistent's PersistValue or something like Preserves)
<isd>
Probably makes sense to use capnp for the serialization format :P.
<fr33domlover>
Haha absolutely
<isd>
But yeah, one way we could do this is just model the datatypes from Data.Generic in a capnp schema, and then serialize to that.
<isd>
So you'd have to do deriving(Generic) on your datatype.
<isd>
but that's it
<isd>
Sorry GHC.Generics
<isd>
Anyway, I think I will work on the "manual" version of this first.