Change:
with python3.pkgs; buildPythonApplication rec { pname = "matrix-synapse"; <del> version = "1.86.0"; </del> <ins> version = "1.87.0"; </ins> format = "pyproject"; src = fetchFromGitHub { owner = "matrix-org"; repo = "synapse"; rev = "v${version}"; <del> hash = "sha256-vSNAISWTTT3IAeA8hxQhQNp9T3soey4vgh7v+BxI+K0="; </del> <ins> hash = "sha256-QBg0aIYIncKDCcgjj1cSAugNtLMb83F7MCijTCcn8YM="; </ins> }; cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; <del> hash = "sha256-lPLhh5FkxpBUQ5UH6eAfUIyGvHIcZHmbYBT5QUW/W4k="; </del> <ins> hash = "sha256-+QFa3NrzDrCniHpbP+pFWImMh9FHERFTRzbEiP4p/7Y="; </ins> }; postPatch = ''

Discussion:
The upgrade to matrix-synapse 1.86.0 is causing a failure when used on at least a number of systems outside of nix is the specific error I'm having this issue as well when I did the upgrade. I have identical output to the issue above. This version has been backported to 22.11 and 23.05. This is an original software error, I do not know what can be done on this end - thought it was worth reporting here in case anyone has the same error. Steps to reproduce the behavior: from matrix-synapse 1.85.2 to the current 23.05/22.11 commits service starts, the above issue happens causing the server to not be able to start Service is able to start. If applicable, add screenshots to help explain your problem. I have currently locked my nix flake to commit to to keep at the previous version for now. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The issue was introduced in Synapse v1.86.0. The solution is to rollback to v1.85.0 until a fix (wip: ) is introduced in a new release; likely v1.87.0, expected to release July 4th 2023.
Ouch, this just bit me. Figured a way to roll back with , watch out - the build will run the whole Synapse test suite. This is an original software error, There is an element of the packaging community failing to catch it and delivering broken software as "stable", though.
This rollback expression worked for me:
Indeed. Presumably this works fine when not upgrading a database so a test for this would be tricky to implement. Either way, at least there's a workaround.
you can avoid the rebuild by using an overlay to override the package with the version from the older, working release:
Well, upgrades are of course tested by maintainers before merging this. However, we all use postgres I guess.
Thanks for the tip Overlays previously seemed like, well, overkill - but now I understand them a little better. Saved for future reference and looking forward to the upstream fix :wave:
Same here, and going back for now.

a production server Maybe we should add a to at least notify old users that their database is not production capable. As an aside I feel bad for who keeps getting mentioned in issues instead of me .
Where did you see that note about database recommendations? I've been using Synapse for years with a SQLite database. I didn't realize I was living on the edge.
E.g. in https://matrix-, but also at the very top is a brief note: https://matrix- Adding a note to the manual is fine, but I don't think we should implement safe-guards for every single_ thing people might do wrong. This is IMHO not our responsibility as maintainers anymore.
Ah, thanks. It looks like those notes were after I did my installation ( in and ). I'll have to figure out the migration process. I think a note in the upgrade instructions of the manual would be sufficient - just something to retroactively draw attention to the deprecation upstream.
Adding a note to the manual is fine, but I don't think we should implement safe-guards for every single thing people might do wrong. This is IMHO not our responsibility as maintainers anymore. Then we should remove the automatic switch on state version and force sqlite users to configure it themselves. The fact that we default to this behavior makes it a little our responsibility
Which behavior specifically? Also, sqlite is the upstream default as well: (source: https://matrix-)
Since we no longer automatically provision the database, we can just remove this stateversion switch, default to postgres, and just fail early for sqlite users if not explicitly set.