TeamHub App Settings Page Conflicts With Teams in Contacts App

ℹ️ Support
1

Hi all,

I am seeing an issue with the TeamHub app where posting a message to a team fails with a 500 error.

I have also raised this on GitHub here:
https://github.com/JustinDoek/Nextcloud-Teamhub/issues/26

Issue

When trying to post a message in TeamHub, the request fails and the server log shows:

Failed to create message: Circle not found

The failed request is:

POST /apps/teamhub/api/v1/teams/[teamId]/messages

The log then shows:

OCA\Circles\Exceptions\CircleNotFoundException
Message: Circle not found

From what I can see, TeamHub is still referencing a team/circle ID that no longer exists or is no longer available through the Circles/Teams backend.

Environment

Nextcloud version: 33.0.3.2
App involved: TeamHub
Related app: Circles / Teams
Browser: Chrome on Windows

What I found

The issue appears to happen when the team becomes missing from the Contacts app / Teams interface, while TeamHub still has a reference to it. I also found out that editing the settings in TeamHub App is what is causing the Team to vanish from Contacts App.

To avoid triggering the same issue again, I have found that team options should only be edited through the Contacts app, rather than editing the team options directly through TeamHub.

Recovery method I found

The only fix I have found so far to recover from the missing team state was:

  1. Delete the affected team from the TeamHub Admin Panel.

  2. Re-add the team through the Contacts app.

It is important to delete the team from the TeamHub Admin Panel first. Otherwise, re-adding the team in Contacts can leave a duplicate entry or inconsistent state in TeamHub.

The TeamHub Admin Panel seems to be the only safe UI-based way to remove the broken TeamHub reference, unless you know how to manage or repair the underlying Circles/Teams data directly using occ.

I have not attempted to repair this directly with occ, as I am not certain which Circles/Teams commands would safely remove or repair the orphaned TeamHub reference without causing further data inconsistency.

Expected behaviour

If the underlying Circle/Team no longer exists, TeamHub should ideally detect this and either:

  1. hide the missing team from TeamHub,

  2. show an admin warning that the linked Circle/Team cannot be found,

  3. provide a repair action in the TeamHub Admin Panel, or

  4. prevent duplicate entries when the team is recreated through Contacts.

Actual behaviour

TeamHub continues to reference the missing Circle/Team, and posting to the team fails with:

Circle not found

Question

Is the intended workflow that Teams/Circles should only be edited through the Contacts app?

If so, it may be useful to document this clearly, or to add safeguards in TeamHub so that changing team options through TeamHub does not leave TeamHub pointing to a missing Circle.

Also, is there a recommended occ method to list, repair or remove orphaned Circles/Teams safely, or is deleting the broken team from the TeamHub Admin Panel and recreating it through Contacts currently the safest approach?

2

Thank you for such a thorough write-up — you have clearly done your homework: reproduced the issue, identified the root cause, found a workaround, documented the recovery steps, and already filed the GitHub issue. That is exactly the right approach, and the GitHub issue is precisely where this belongs.

Unfortunately this is not something that can be meaningfully discussed or resolved here in the forum. The reason goes beyond the specific bug:

TeamHub shows strong characteristics of vibe-coded software:

  • Chaotic versioning: 45 tags in under 7 weeks, with version numbers that are neither sequential nor consistent. The first release was simply tagged Development. Tags alternate between v-prefixed and bare numbers (v3.37 vs 3.24). The same version appears twice on the same day (v3.13 and 3.13.0). Version numbers skip non-linearly (v3.4 → v3.6, v3.23 → v3.27.2, v3.28 → v3.32.2). Most strikingly, tag 3.2.0.1 was published after 3.18.3 — the version number runs backwards relative to time. This is not Semantic Versioning in any recognisable form.
  • Inconsistent code style: parts of the codebase show careful, technically precise comments and proper patterns; other parts show trivial boilerplate comments and duplicate dependency lookups that suggest separately-prompted code never reviewed as a whole.
  • Missing edge case handling: the specific bug you hit — orphaned Circle references after editing team options — points to operations that were implemented without systematically validating pre-conditions.

For an app at this stage of maturity, with this release velocity, the only place where a bug can realistically get fixed is the GitHub repository. Forum discussion cannot substitute for that.

I am closing this thread and directing you back to your GitHub issue:

ernolf