| 18 Sep 2023 |
 hexa | events can be striped across multiple workers, most other things (typing, to_device, account_data, receipts, presence) cannot | 18:07:06 |
| hexa | synapse will fail to boot when you configure a list where it expects a string, ask me how I know | 18:07:55 |
| hexa | * synapse will fail to boot when you configure a list of workers where it expects a just a single one, ask me how I know | 18:08:13 |
 Dandellion | that's right, it's also why my module only supports event persisters for now | 18:09:00 |
 ma27 | In reply to @hexa:lossy.network
synapse will fail to boot when you configure a list of workers where it expects a just a single one, ask me how I know oh, you too :D | 18:09:04 |
| ma27 | currently on the phone, will respond later | 18:09:16 |
| Dandellion | since abstracting the other stream writers required a little more work at the time | 18:09:33 |
| Dandellion | * since abstracting the other stream writers properly required a little more work at the time | 18:09:45 |
| hexa | as the worker setup is very brittle, we should probably try to co-maintain most of the thing | 18:12:06 |
| hexa | * as the worker setup is very brittle, we should probably try to co-maintain most of the code | 18:12:12 |
| hexa | * as the worker setup is very brittle, we should probably try to co-maintain most of the code required for a productive worker setup | 18:12:43 |
| hexa | and not let everyone come up with a weird downstream solution | 18:12:50 |
| hexa | * and not let everyone come up with an even weirder downstream solution | 18:13:07 |
 f0x | In reply to @hexa:lossy.network
and not let everyone come up with an even weirder downstream solution ha ha sweats | 18:14:42 |
| hexa | I was not looking at you, I swear! | 18:15:02 |
| Dandellion | I think maintaining the map and making opinionated types of workers is something that should be in nixpkgs. I'm not sure what you are arguing for | 18:16:31 |
| ma27 | In reply to @dandellion:dodsorf.as
I think Ma27 seemed quite negative about this generally, But personally I think just putting the maps inside services.nginx.commonHttpConfig is more than adequate even without RFC-42 nginx (Which I think is basically impossible without introducing some kind of DAG system similar to home-manager)
But I'll be changing my module to match the nixpkgs implementation and work towards upstreaming the autoconfig stuff
so, in case of an rfc42 compliant nginx module I'd be all in favor. ANd now back to reality ;-)
I'm somewhat afraid that we'll come up with something that will be incomplete and if you need to change something, you'll need to touch the module rather quickly or need something else (which is an actual problem with the nextcloud module).
However, two things: first of all, after having played around with my synapse and messed up a few things while doing that (e.g. read receipts being broken because of an nginx misconfiguration) I think that mweinelt has a point here. Also, it's a purely opt-in thing, so it might not be that bad after all. That said, is the current module on your github in a reviewable state? | 19:12:23 |
| hexa | yeah, workers did in fact introduce subtle breakages for me as well, like crypto intermittently stopped working 😄 | 19:53:16 |
| hexa | traced that back to the stream writers, and disabled all but events as well | 19:53:37 |
