I saw this in my logs:
2026-04-06 15:42:35.304 [WARN ] [.io.rest.auth.internal.TokenResource - 257054 ] - Not refreshing token for session [redacted] of user erik, missing or invalid session cookie
2026-04-06 15:42:35.318 [WARN ] [.io.rest.auth.internal.TokenResource - 257054 ] - Token issuing failed: invalid_grant
I assume this was when I tried to open the UI in the Chrome app on my Android phone. Is this expected behavior? (The tag WARN doesn’t give that impression…)
WARN doesn’t mean something is wrong. It means something unexpected. OH expected there to be a session cookie but no cookie was found. Therefore, it couldn’t refresh the authentication token, it had to go through the full authentication process again.
I’d guess you had to re log in to MainUI unless you have explicit user role enabled.
What likely happened was Chrome cleared its cookies.
I do find this a bit counter intuitive… I associate the word ‘warning’, as well as the orange color of WARN messages with ‘danger’…
If this is the normal procedure, why not make it a INFO logging?
TRACE is where you log everything you can think of into really understand what the code is doing. “I received this message and extracted the first element. I extracted the second element. …”
DEBUG you log less and leave out some of the repetitive stuff TRACE includes. “I received a message and successfully parsed it.”
INFO is reserved for log statements that inform the end user of something important during normal operation. INFO is the default logging level. “All your zwave devices are online.” Very little gets logged out at the INFO level because these statements need to be relevant to the end user during normal operating conditions.
WARN is reserved for log statements informing the end user that something unexpected happened, but it did not cause OH to malfunction in any way. A WARN level log could indicate a problem, but usually it’s just informative. “I expected X and X wasn’t there, but I worked around it.”
ERROR is reserved for log statements indicating that a malfunction occurred and OH was not able to work around it. “No permission to read/write to Zigbee controller socket.”
A warning is more than just informational. But it does not mean OH is malfunctioning. If the cookie is expected to not be there under normal operating conditions, the log would be INFO or more likely even DEBUG.
But if the cookie is expected to be there under normal operating conditions and it’s not, but OH can still proceed, that’s a warning. This may or may not indicate a problem somewhere. It’s just something to watch out for. If you get the same warning over and over again for a long period of time, you may need to look into it more. If it happens once, or once every several months, nothing is wrong.
When I go hiking and see a warning sign that says “Caution, bears may be present”, it doesn’t mean bears are eating my leg. It means I need to watch out. I may never even see a bear on my hike, but it’s a possibility. Warning log statements are the same.