500 error when assigning a user to a thread
I've been using the new thread assigning feature on the TinyPilot forum, but it's no longer working for me. I keep receiving a 500 internal server error whenever I click save. My team members are still able to assign users to threads, however.
I'm using Firefox 112.0.2.
Here's the error:
Error 500 Internal Server Error
Something went wrong: [DwE500REX]
java.lang.RuntimeException: s1516: Notf to self, id: 563, about post id 2610 [TyE4S602MRD5]
at com.debiki.core.Prelude$.die(Prelude.scala:259)
at com.debiki.core.Prelude$.dieIf(Prelude.scala:279)
at talkyard.server.notf.NotificationGenerator._genOneNotfMaybe(NotificationGenerator.scala:1081)
at talkyard.server.notf.NotificationGenerator.maybeMakeNotfs$1(NotificationGenerator.scala:838)
at talkyard.server.notf.NotificationGenerator.$anonfun$_makePostSubscrNotfFor$8(NotificationGenerator.scala:755)
at talkyard.server.notf.NotificationGenerator.$anonfun$_makePostSubscrNotfFor$8$adapted(NotificationGenerator.scala:743)
at scala.Option$WithFilter.foreach(Option.scala:407)
at talkyard.server.notf.NotificationGenerator.$anonfun$_makePostSubscrNotfFor$4(NotificationGenerator.scala:743)
at talkyard.server.notf.NotificationGenerator.$anonfun$_makePostSubscrNotfFor$4$adapted(NotificationGenerator.scala:742)
at scala.collection.TraversableLike$WithFilter.$anonfun$foreach$1(TraversableLike.scala:985)
at scala.collection.Iterator.foreach(Iterator.scala:943)
at scala.collection.Iterator.foreach$(Iterator.scala:943)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1431)
at scala.collection.IterableLike.foreach(IterableLike.scala:74)
at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
at scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:984)
at talkyard.server.notf.NotificationGenerator._makePostSubscrNotfFor(NotificationGenerator.scala:742)
at talkyard.server.notf.NotificationGenerator._genWatchingSomethingNotfs(NotificationGenerator.scala:487)
at talkyard.server.notf.NotificationGenerator.generateForAssignees(NotificationGenerator.scala:1055)
at debiki.dao.PostsDao.$anonfun$addRemovePatNodeRelsIfAuZ$1(PostsDao.scala:2637)
at debiki.dao.SiteDao.$anonfun$writeTx$2(SiteDao.scala:263)
at debiki.dao.SiteDao.$anonfun$readWriteTransaction$2(SiteDao.scala:303)
at com.debiki.core.DbDao2.readWriteSiteTransaction(DbDao2.scala:67)
at debiki.dao.SiteDao.$anonfun$readWriteTransaction$1(SiteDao.scala:303)
at debiki.dao.SiteDao$.siteWriteLockIdImpl(SiteDao.scala:822)
at debiki.dao.SiteDao$.$anonfun$withSiteWriteLock$1(SiteDao.scala:811)
at debiki.dao.SystemDao$.withWholeDbReadLock(SystemDao.scala:879)
at debiki.dao.SiteDao$.withSiteWriteLock(SiteDao.scala:811)
at debiki.dao.SiteDao.readWriteTransaction(SiteDao.scala:302)
at debiki.dao.SiteDao.writeTx(SiteDao.scala:279)
at debiki.dao.SiteDao.writeTx(SiteDao.scala:250)
at debiki.dao.PostsDao.addRemovePatNodeRelsIfAuZ(PostsDao.scala:2517)
at debiki.dao.PostsDao.addRemovePatNodeRelsIfAuZ$(PostsDao.scala:2512)
at debiki.dao.SiteDao.addRemovePatNodeRelsIfAuZ(SiteDao.scala:113)
at controllers.PageController.$anonfun$changePatNodeRels$1(PageController.scala:258)
at scala.Function1.$anonfun$andThen$1(Function1.scala:57)
at talkyard.server.http.PlainApiActions$$anon$1.runBlockIfAuthOk(PlainApiActions.scala:714)
at talkyard.server.http.PlainApiActions$$anon$1.invokeBlockAuthViaCookie(PlainApiActions.scala:453)
at talkyard.server.http.PlainApiActions$$anon$1.invokeBlockImpl(PlainApiActions.scala:250)
at talkyard.server.http.PlainApiActions$$anon$1.invokeBlock(PlainApiActions.scala:136)
at talkyard.server.http.PlainApiActions$$anon$1.invokeBlock(PlainApiActions.scala:109)
at play.api.mvc.ActionBuilder$$anon$9.apply(Action.scala:379)
at talkyard.server.http.PlainApiActions$$anon$1.$anonfun$composeAction$1(PlainApiActions.scala:123)
at talkyard.server.http.SafeActions$ExceptionAction$.invokeBlock(SafeActions.scala:126)
at talkyard.server.http.SafeActions$ExceptionAction$.invokeBlock(SafeActions.scala:83)
at play.api.mvc.ActionBuilder$$anon$9.apply(Action.scala:379)
at play.api.mvc.Action.$anonfun$apply$4(Action.scala:82)
at play.api.libs.streams.StrictAccumulator.$anonfun$mapFuture$4(Accumulator.scala:168)
at scala.util.Try$.apply(Try.scala:213)
at play.api.libs.streams.StrictAccumulator.$anonfun$mapFuture$3(Accumulator.scala:168)
at scala.Function1.$anonfun$andThen$1(Function1.scala:57)
at scala.Function1.$anonfun$andThen$1(Function1.scala:57)
at play.api.libs.streams.StrictAccumulator.run(Accumulator.scala:200)
at play.core.server.AkkaHttpServer.$anonfun$runAction$4(AkkaHttpServer.scala:424)
at akka.http.scaladsl.util.FastFuture$.strictTransform$1(FastFuture.scala:41)
at akka.http.scaladsl.util.FastFuture$.$anonfun$transformWith$3(FastFuture.scala:51)
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:63)
at akka.dispatch.BatchingExecutor$BlockableBatch.$anonfun$run$1(BatchingExecutor.scala:100)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:85)
at akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.scala:100)
at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:49)
at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:48)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
KajMagnus @KajMagnus2023-06-01 13:07:47.973ZHi Dave, ok that's a bug, I'll look into that (today / tomorrow). Sorry for the troubles. Thanks for posting & the stack trace.
KajMagnus @KajMagnus2023-06-02 20:35:11.567ZI think I've found the problem — should be a quick fix, early next week I think.
What's happening is (or at least the stack trace suggests this, and I can reproduce it) that 1) you have recently subscribed to notifications about all posts and comments for that page or parent category or the whole site (?), and therefore 2) Talkyard tries in a "new" way to send you notifications that someone (you) is getting assigned (by yourself). But 3) other code in Talkyard notices that it's trying to send you a notification about something you did, and it shouldn't do that so 4) an assertion fails and you see the error message.
- In reply todaveb⬆:KajMagnus @KajMagnus2023-06-04 18:16:00.922Z
Hi Dave, This should have been fixed now. Would you like to try?
***
I added a keyboard shortcut, so you can hit the keys atm to assign a topic to you, (short for "Assign To Myself"), when you are looking at a topic that you want to assign to yourself (and you don't have the editor focused, typing things there).
But first you need to enable shortcuts — you can do that, here:
https:// Talkyard server /-/users/daveb/preferences/ui(if you'redavebthere too). Copy-paste this JSON:{"kbd": 1}into the JSON config and click Save. It means "Keyboard shortcuts enabled (1)".
@davebFantastic! Looks like it's working now - thanks for fixing this for me. And thanks for the keyboard shortcut! I'll have to get used to using it, but it definitely seems more convenient than the current UI flow for assigning threads.
Thanks again!
- KajMagnus @KajMagnus2023-06-05 05:55:49.796Z
Ok :- ) Marking this as done then, for now. Hmm yes I suppose the shortcuts take a while to get used to. I slightly keep forgetting that they exist, too. Maybe if everything was possible via shortcuts — like in Vim — so one could use them always, it'd be simpler to remember.
- Progresswith handling this problem