Closed as released, but the public ROR record still appears unchanged

[swinarew-dot]

🏷️ Discussion Type

Bug

Topic area

Other

Body

I am trying to understand how best to proceed when an issue in a public repository is marked as completed and released, but the corresponding public-facing record still appears unchanged. In this case, I expected the public ROR record to reflect the approved metadata changes after the issue had been processed, included in milestone v1.74, marked as “Record updated in release v1.74,” closed as completed, and given the project status “Done (Released on Production).” However, although the issue history indicates that the request was treated as resolved and published, the current public ROR page for the same record still appears not to reflect those approved changes.

For reference, the issue history showing the request as completed and released is here:
ror-community/ror-updates#25164

The current public ROR record for the same entry is here:
https://ror.org/05xaz0w84

Because of this mismatch between the issue history and the current public-facing record, a more precise follow-up request was later submitted here:
ror-community/ror-updates#32183

I would appreciate guidance on the best way to handle a situation like this while avoiding duplicate requests and confusion.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[itxashancode]

This scenario is not a GitHub platform bug, but rather a common workflow disconnect between GitHub's issue tracker and an external deployment pipeline. The ror-community/ror-updates repository uses GitHub Issues as a ticketing queue to stage metadata changes for the ROR registry. When an issue is labeled “Released on Production,” it indicates the maintainers merged the change and triggered the sync process. However, external databases, API propagation delays, or CDN caching can cause the public-facing record to lag behind.

Here’s how to handle this efficiently on GitHub while avoiding duplicate tracking:

🔍 1. Verify Deployment & Sync Status First

Before escalating, confirm whether the change actually left GitHub and reached the external system:

• Check the Actions tab for the repository to see if the release/deployment workflow completed successfully.
• Look for automated bot comments that typically post deployment hashes, sync timestamps, or API response codes.
• Review the Releases page for v1.74 to confirm the changelog includes your record.

💬 2. Comment on the Original Issue (Do Not Duplicate)

GitHub's tracking system relies on centralized context. Instead of opening a new issue (#32183), add a follow-up comment to #25164:

@maintainer-handle The issue is closed and marked as released in v1.74, but the public record at https://ror.org/05xaz0w84 still reflects the previous metadata. Could you verify if the production sync completed successfully? I've attached a cache-bypassed API check for reference.

This preserves the audit trail, notifies watchers, and prevents fragmented triage.

🔄 3. Reopen the Issue If the Sync Failed

Only users with Write access or the original author can reopen closed issues. If maintainers confirm the deployment was skipped or failed, request a reopen:

“If this change wasn't pushed to production, please reopen this issue or let me know the preferred escalation path.”

If you lack permissions, a maintainer can reopen it via the UI or by pushing a commit referencing Closes #25164 (which keeps it closed intentionally).

🛠 4. Use Cross-Referencing & Project Labels

• Always link related issues using #issue-number (GitHub auto-links and creates backreferences).
• Apply labels defined in the repo's labels list (e.g., sync-delay, needs-verification). Avoid creating custom labels unless you're a maintainer.

🌐 5. Bypass Local Caching to Confirm State

Web UIs often cache aggressively. Verify the live backend state using the ROR API:

curl -s -H "Cache-Control: no-cache" \
  https://api.ror.org/organizations/05xaz0w84 | \
  jq '{name: .name, status: .status, last_modified: .last_modified}'

If the API shows the updated metadata but the web UI does not, it's a frontend cache issue. Mention this explicitly so maintainers can route it to their web/CDN team rather than the data pipeline.

✅ Best Practices for Future Requests

• Always check CONTRIBUTING.md or issue templates for project-specific sync SLAs (many registries update on a 24–72 hr cycle).
• Avoid duplicate issues unless maintainers explicitly request them. Fragmented tracking breaks automation and slows triage.
• Use GitHub Discussions if the project uses them for release announcements or known sync delays.

For official guidance on managing issue lifecycles and cross-referencing, see:

• Managing issues and pull requests
• Autolinked references and URLs
• Reopening closed issues

By keeping follow-ups threaded to the original issue, verifying external state via API, and deferring to the project's documented sync cadence, you'll minimize confusion and help maintainers resolve deployment gaps faster.