while checking my production log I found a lot (more than 1900) of entries like this:
2017-09-22T06:17:12] ERROR PID-1649 TID-70251678282980 DiasporaFederation::Federation::Receiver: failed to receive public message: DiasporaFederation::Salmon::MissingAuthor: DiasporaFederation::Salmon::MissingAuthor
What does this mean? And is there a way to turn up the loglevel? I only found something debugging-related in the developer FAQ (but I have no development.log as my pod runs in production mode).
There is nothing you can do about this, when the author is missing then it is missing.
I don’t know from where you receive these messages, but without the author it’s difficult to see that This error message happens only when you receive something broken via the old federation protocol (because the new protocol doesn’t have this author field anymore). It’s strange that you have this message that often, because I don’t have it even one in my log.
You can enable federation debug logging in the diaspora.yml, then it will print the raw received XML to the log. The log is production.log when you run in production mode.
thanks for your reply. It seems that somehow my installation is broken. Federation logging was already activated but I don’t see any XML in my production.log (or where is it logged?).
Additionally I did some further investigation on this: I checked some accounts on different pods that share with me. When I compare the accounts stream on my pod and the public stream on the remote pod there are several posts missing on my pod. And the remote pods run on 0.7.0.x. So I assume that - for whatever reason - my pod declines posts from other pods because the author is missing. I didn’t check the remote profiles on other pods but I suppose that if it is an error in the federation it would have been already noticed.
Anyway, I already thought about setting up a new pod on another domain with public registration. So I will shut down my pod and set up the pod with the new domain.
When posts from 0.7.x fail, then you have a problem with your setup, because 0.7.x sends the new protocol. Do you manipulate headers (Content-Type) in your webserver? Because that’s what is used to detect if it’s the old or new protocol. When you try to parse the new protocol the old way, this obviously fails … because the new protocol doesn’t have this wrapper with the author anymore.
I use the recommended Apache setup and I only enforce HTTPS with RequestHeader set X_FORWARDED_PROTO https - or has this changed with 0.7.0.0? I will check the linked Apache config in the installation guide.
But why does my Diaspora fail parsing responses from other pods if my webserver sends wrong headers? Wouldn’t it be the other way round?
The really strange thing is that some posts are received and some not (from the same remote account) - so if Apache would modify the headers wrong no remote post would be received.
I don’t know apache, I use nginx on my pods. So maybe somebody with apache knowledge can help you.
Some posts are maybe received via fetching (which always uses the new protocol).
Oh, and by the way: I just realized that the debug logging for federation only logs it when it doesn’t fail that early (because it logs the inner xml, not the salmon). So it won’t help you here (but it also isn’t the problem here, because when you receive the new protocol without the Content-Type header the xml isn’t the problem).
OK, @michaelvogel just told me, that the relay sends data from the new protocol via the old way, that explains your errors. So it’s not your fault. I don’t have the relay enabled, that’s why I don’t have this error. Sorry for the confusion.
So this is the fixed image with the route of a message to your pod with the relay enabled:
other pods -> relay -> your webserver -> your diaspora
^
\ here the header is lost
@jaywink can you have a look at this bug of the relay? All messages from 0.7.x pods from the relay are invalid.
This error message happens only when you receive something broken via the old federation protocol (because the new protocol doesn’t have this author field anymore). It’s strange that you have this message that often, because I don’t have it even one in my log.