No internet connection
  1. Home
  2. Issues

Error when accessing a Topic through a notification

By @Mr.Nobody
    2023-11-07 21:01:53.589Z

    I'm getting this weird error when clicking on a notification of someone else posting a topic in a category I'm following.

    The link of the notification is:

    If I access the topic regularly, without the #post-1, the bug doesn't happen.
    it also doesn't happen when accessing the forum through the regular URL:

    Error 500 Internal Server Error

    Something went wrong: [DwE500REX]
    java.lang.RuntimeException: 1699054208|LcHtEYdAWq3y [TyE2ABK49Z3]
    	at com.debiki.core.Prelude$.die(Prelude.scala:297)
    	at com.debiki.core.Prelude$.dieIf(Prelude.scala:317)
    	at talkyard.server.http.PlainApiActions$$anon$1.invokeBlockAuthViaCookie(PlainApiActions.scala:444)
    	at talkyard.server.http.PlainApiActions$$anon$1.invokeBlockImpl(PlainApiActions.scala:262)
    	at talkyard.server.http.PlainApiActions$$anon$1.invokeBlock(PlainApiActions.scala:137)
    	at talkyard.server.http.PlainApiActions$$anon$1.invokeBlock(PlainApiActions.scala:110)
    	at play.api.mvc.ActionBuilder$$anon$9.apply(Action.scala:379)
    	at talkyard.server.http.PlainApiActions$$anon$1.$anonfun$composeAction$1(PlainApiActions.scala:124)
    	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.core.server.AkkaHttpServer.$anonfun$runAction$4(AkkaHttpServer.scala:429)
    	at akka.http.scaladsl.util.FastFuture$.strictTransform$1(FastFuture.scala:41)
    	at akka.http.scaladsl.util.FastFuture$.$anonfun$transformWith$3(FastFuture.scala:51)
    	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$
    	at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:85)
    	at akka.dispatch.BatchingExecutor$
    	at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:48)
    	at java.base/java.util.concurrent.ForkJoinTask.doExec(
    	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(
    	at java.base/java.util.concurrent.ForkJoinPool.scan(
    	at java.base/java.util.concurrent.ForkJoinPool.runWorker(
    	at java.base/
    • 3 replies
    1. KajMagnus @KajMagnus2023-11-08 10:54:44.368Z2023-11-08 13:01:38.705Z

      That's odd, looks as if in the XSRF token, there's a pipe | instead of a dot . .

      The notification, is it a link in an email, or is it in one's username dropdown menu in the forum?

      Can you still reproduce the bug? If so, what if you open Dev Tools, start a recording session in the Network tab, then reproduce the bug, and then right click anywhere in the network requests list, and select Save all as HAR with content and send to me in a PM or email? (Then I'd also get your session cookie, but, hmm, I have access to the server anyway. Nevertheless, you'd better log out & in again, some time later.) — Sorry for the distraction from what you would otherwise have been doing.

      Or if that's too intrusive — what if you open Chrome Dev Tools (if you use Chrome): CTRL+I, then click the Application tab, click Cookies to the left (below Storage), and copy the value of the XSRF-TOKEN cookie, and send in a private message? Hmm seems it's already included in the error log message, but might be good to copy it via Dev Tools too.


      This weird XSRF token (with a |) is old, from before HTTPS started working, but I'm still confused about how the | not a . has happened.

      (Old? The first part of the XSRF token, is a timestamp, and it's from Friday November 3, which is before I added HTTPS to the forum, which was on November 5.)

      I suspect that if you log out, and log in again, the problem will be gone. Hmm at the same time, then maybe we cannot reproduce it any more. — Still, I could add a warning log message to the server, and auto-generate a new XSRF token if this happens again.

      When accessing via the .... domain, the XSRF cookie won't get sent (different domain) so then the server never sees the unusual | instead of ., so the error won't happen.

      About the url ending with ...#post-1, or without #post-1. Somehow, the #post-1 request is (or triggers) a HTTP POST request, which triggers the XSRF check. But when you access without #post-1, then a normal GET request happens, and then the XSRF check won't run, so the error won't happen. — Does the error message pop up immediately? Or is there a small delay? (In the latter case, maybe it's in fact another request, which tracks reading activity, that in fact triggers the error. It's a POST.)

      (You're using "normal" browser, not cURL or some other tool?)

      1. @Mr.Nobody
          2023-11-08 19:09:30.315Z

          The notification, is it a link in an email, or is it in one's username dropdown menu in the forum?

          it is the in-app notification in the forum. But if I copy the URL and paste it into a new window it also happens.
          However, today this bug isn't appearing anymore. It is however appearing when I try to resume the editing of a draft.
          Can this be because I added the new domain but didn't enable to redirect yet? in the normal URL this issue doesn't happen, just in the new "custom" url. I haven't enabled the redirect yet though, because of this issue.

          So I am sending you the recording of the draft issue per email.

          1. Thanks! I've had a look at the HAR. It looks as if the weird XSRF token is not Talkyard's cookie. You have added some custom Javascript code? Some plugin maybe?

            XSRF-TOKEN is a pretty common name for XSRF cookies (for example, AngularJS use(d) it as its default XSRF cookie name). And in the HAR file, I see another cookie that also isn't Talkyard's. I replied to the email a bit about that.

            So, I think I'll rename Talkyard's XSRF cookie to TyCoXsrf, so there won't be any cookie collisions in the future. I'll do, and release a new server, together with a few other bug fixes.

            (In the HAR file, I see both this "weird" XSRF-TOKEN cookie with a format that makes Talkyard say "Error", and also Talkyard's own XSRF-TOKEN cookie, the precise same name and with the expected format & contents. But it appears later in the cookie header, so Talkyard won't use it — instead, the "werid" cookie value gets used instead.)

            (It was indeed a POST request to for tracking reading activity that triggered the error, not the view-page GET request — Talkyard was trying to mark the page as read.)

            Can this be because I added the new domain but didn't enable to redirect yet? in the normal URL this issue doesn't happen, just in the new "custom" url

            The old domain (at Ty .net) probably doesn't have those extra cookies, for some reason.

        • Progress
          with handling this problem
        • @KajMagnus marked this topic as Started 2023-11-09 07:22:14.473Z.