Sametime 12.0.4 – Chat stops working after proxy container restart

MarcFinte · October 2, 2026, 3:40pm

Sametime Version: 12.0.4
Operating System: Ubuntu

Hello everybody,
we are experiencing a problem with the Sametime proxy container after a restart.

Before restarting the proxy container, everything works normally:

Users can log in successfully.
Users can start and join meetings without problems.
Chat messaging works correctly via Web and Client.

However, after the first restart of the Sametime proxy container, the behavior changes:

Users can still log in successfully.
Meetings can still be started.
Chat via the HCL Notes client continues to work correctly.
However, users can no longer send messages using the Sametime web chat.

The fact that authentication continues to work and that chat through the Notes client is unaffected makes an LDAP or general Sametime backend problem unlikely.

Relevant error

innerExecute invalid userId:cn=John,ou=People,o=orgA,ou=organizations,dc=co-dmz,dc=local stUser:INVALID_USER

get-sync INVLD userId:cn=John,ou=People,o=orgA,ou=organizations,dc=co-dmz,dc=local stUser:com.lotus.sametime.core.types.STUser@78601464 name = badName id = {{badId,badCommunity}}  desc = badDesc

LOG

c.hcl.sametime.proxy.STAbstractService   : com.hcl.sametime.proxy.chat.ChatTransaction.innerExecute user:st[F3A0EBFAAD3F9A55DA7479CCE60B1EFD] user[cn=Max,ou=People,o=orgA,ou=organizations,dc=co-dmz,dc=local] type[Web-11   ] remoteAddr[172.19.0.3] http[400] error[Bad Request] exception:null
c.h.sametime.proxy.chat.ChatTransaction  :   innerExecute invalid userId:cn=John,ou=People,o=orgA,ou=organizations,dc=co-dmz,dc=local stUser:INVALID_USER
c.h.sametime.proxy.chat.ChatTransaction  : > innerExecute
c.h.sametime.proxy.chat.ChatController   : > sendChat userId: cn=Jon,ou=People,o=orgA,ou=organizations,dc=co-dmz,dc=local msg: 
com.hcl.sametime.proxy.STCustomCsrf      : > loadToken req:org.springframework.security.web.header.HeaderWriterFilter$HeaderWriterRequest@42d8c20f
com.hcl.sametime.proxy.STCustomCsrf      : < F3A0EBFAAD3F9A55DA7479CCE60B1EFD handle    SKIPPED :POST /stwebapi/chat
com.hcl.sametime.proxy.STCustomCsrf      : < F3A0EBFAAD3F9A55DA7479CCE60B1EFD matches   TRUE    :POST /stwebapi/chat
com.hcl.sametime.proxy.STCustomCsrf      : < F3A0EBFAAD3F9A55DA7479CCE60B1EFD loadToken LOADED  :token:XXXXXX-XXXX-XXXX-XXXX-64a2ab5a8234
c.hcl.sametime.proxy.ResolvedUserCache   : > get-sync userId:cn=John,ou=People,o=orgA,ou=organizations,dc=co-dmz,dc=local sid:F3A0EBFAAD3F9A55DA7479CCE60B1EFD
c.hcl.sametime.proxy.ResolvedUserCache   : < get-sync INVLD userId:cn=John,ou=People,o=orgA,ou=organizations,dc=co-dmz,dc=local stUser:com.lotus.sametime.core.types.STUser@78601464 name = badName id = {{badId,badCommunity}}  desc = badDesc
c.h.sametime.proxy.chat.ChatTransaction  : < innerExecute
c.h.sametime.proxy.chat.ChatController   : < sendChat 
com.hcl.sametime.proxy.JwtTokenFilter    : < doFilterInternal type:REQUEST uri:/stwebapi/chat

As a temporary workaround, we can restore the original working behavior by using dbutility to delete all users once; after that, chat works normally until the next proxy container restart.

Has anyone encountered this behavior in Sametime 12.0.4?

alearriaga · October 3, 2026, 1:49am

Hi Marc,

I agree this doesn’t look like an LDAP or general backend problem. Login, meetings and Notes client chat all still work. Only web chat fails, and only after the proxy restarts. That points to the Sametime proxy failing to look up the chat recipient after the restart. In your log, the recipient comes back as INVALID_USER (badName / badId,badCommunity), and the proxy rejects the send with HTTP 400. Deleting users with dbutility clears that state, which is why chat works again until the next restart.

Please open an official support case with HCL. The forum is fine for first ideas, but the support team can only fully review the complete proxy and Community logs, compare them against known issues, and pass a possible defect to development through a case.

To speed up the case, please collect the following and attach it to the support case:

1. Environment details

The exact Sametime 12.0.4 build or fix level (including any interim fixes)
Ubuntu version, and whether you use Docker / Docker Compose, Podman or Kubernetes
Whether anything sits in front of the proxy container (reverse proxy, load balancer, etc.).
How the proxy is restarted (docker restart, docker compose restart, full stack down/up, host reboot)
Whether only the proxy is restarted, or other containers too

2. Configuration files

docker-compose.yml and the .env / custom.env files from your Sametime install directory
sametime.ini and notes.ini from the Sametime Community server

3. Logs, covering one full restart cycle
Please capture a fresh reproduction in this order:

Confirm web chat works before the restart (or right after running dbutility).
Note the time, then restart the proxy container.
Try web chat again between the same users and note the time it fails.
Collect the logs:
- Proxy container log from container start through the failed chat
- Logs from the other Sametime containers for the same period (for example the community, auth and mongo containers)
- Sametime Community server logs for the same period
- A browser HAR file (F12 → Network, “Preserve log” on) of the failed web chat send, plus the browser console output

4. Affected user details

One or two example sender/recipient pairs where web chat fails after the restart.
An export of an affected recipient’s user record from MongoDB, taken before and after a proxy restart, so we can compare it with the DN the proxy is trying to look up.

5. Questions that will help narrow it down

After a restart, does web chat fail for every recipient or only some? Do the affected users share the same org/OU?
Do users who never logged in before the restart (so they have no stored record) chat normally?
If you don’t run dbutility, does it ever fix itself after some hours?
If you restart the proxy a second time once all other containers are fully up, does web chat start working?

Best regards,
Ale