chore(release): staging to production - 2026.01.23

[github-actions]

🚀 Release: Staging to Production

Release Date: 2026-01-23

Changes in this release

• fix(AGENT-639): pass entity organizationId/workspaceId in vector store options (734558e)
• fix(ContentfulLoader): exclude archived entries from query results (ee96b8c)

---

This PR is automatically created/updated when commits are pushed to staging.
Merging this PR will trigger the release workflow to create a new GitHub release.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
answerai-docs	Building	Preview	Jan 22, 2026 11:52pm
the-answerai	Building	Preview	Jan 22, 2026 11:52pm

[claude]

🔍 Pull Request Review

This release PR includes two important bug fixes. Overall the changes look good and follow repository conventions, but I have some observations and recommendations.

---

✅ Strengths

1. Multi-tenancy enforcement: The addition of organizationId and workspaceId to vector store options properly addresses AGENT-639 and ensures data isolation per repository requirements
2. Data integrity: The Contentful loader fix prevents archived entries from being processed, improving data quality
3. Defense in depth: Using both query parameter (sys.archivedAt[exists]) and runtime filtering (archivedVersion check) provides robust protection against archived entries

---

🐛 Potential Issues

1. Contentful Pagination Logic Risk (Medium Priority)

// packages/components/nodes/documentloaders/Contentful/Contentful.ts:587
while (this.includeAll && itemsProcessed < total)

Issue: The loop condition uses itemsProcessed (number of items returned by API) but should likely use allEntries.length (number of non-archived items actually collected).

Scenario: If Contentful returns 100 items where 20 are archived:

• itemsProcessed = 100
• allEntries.length = 80
• If total = 150, the loop might exit prematurely thinking it processed 100/150 when it only collected 80 valid entries

Recommendation:

while (this.includeAll && allEntries.length < total)

Or better yet, since the query now excludes archived entries, total from the API should reflect non-archived count, making the original logic correct. Please verify this assumption with the Contentful API documentation.

2. Mixed Filtering Strategy (Low Priority)

The code uses both:

• Query parameter: query['sys.archivedAt[exists]'] = false (line 552)
• Runtime filter: !entry.sys.archivedVersion (line 582)

Question: Are both necessary? If the query parameter works correctly, the runtime filter is redundant. If the query parameter is unreliable, document why both are needed.

Recommendation: Add a comment explaining the defense-in-depth approach or simplify to one method.

---

🔒 Security & Multi-tenancy

✅ Excellent: The vector store changes properly pass organizationId and workspaceId through the options chain, ensuring:

• Data is properly scoped to organizations (critical for multi-tenancy)
• Follows the pattern documented in CLAUDE.md and packages/server/CLAUDE.md

The changes in three locations are consistent:

1. DocStoreVector.ts - Passes to vector store initialization
2. deleteVectorStoreFromStore - Includes in options for deletion operations
3. _insertIntoVectorStoreWorkerThread - Includes in worker thread options

---

📝 Code Quality

1. Error handling: ✅ Existing try-catch blocks remain intact
2. Naming conventions: ✅ Clear variable names (itemsProcessed, nonArchivedItems)
3. Documentation: ⚠️ Missing - No inline comments explaining why both filtering methods are used for Contentful

---

🧪 Testing Recommendations

Missing test coverage - These changes would benefit from:

1. Contentful loader tests:

   • Verify archived entries are excluded
   • Test pagination with mixed archived/non-archived results
   • Edge case: all entries in a page are archived

2. Vector store multi-tenancy tests:

   • Verify organizationId/workspaceId are properly passed through
   • Test that operations respect organization boundaries

Example test structure:

describe('ContentfulLoader', () => {
  it('should exclude archived entries from query', async () => {
    // Mock Contentful API with archived and non-archived entries
    // Verify only non-archived entries are returned
  })
  
  it('should handle pagination when some pages contain only archived entries', async () => {
    // Test edge case pagination behavior
  })
})

---

📊 Performance Considerations

1. Double filtering: Runtime filter after query parameter adds minimal overhead but is worth measuring if dealing with large datasets
2. Pagination efficiency: Current approach processes all pages even if archived - acceptable but could be optimized if performance becomes an issue

---

✏️ Suggested Changes

1. Critical: Verify the Contentful pagination logic (itemsProcessed vs allEntries.length)
2. Recommended: Add comment explaining dual filtering strategy
3. Nice-to-have: Add unit tests for both fixes

---

🎯 Verdict

Approved with minor concerns ✅

The changes are functionally correct and follow repository patterns. The vector store fix is solid. The Contentful pagination logic needs verification but is likely correct if the API's total excludes archived entries.

Action items before merge:

• Verify Contentful API behavior: Does total include archived entries when sys.archivedAt[exists]=false is set?
• Consider adding tests for these scenarios
• Add inline comment explaining the defense-in-depth filtering approach

---

Review conducted following .claude/commands/pr-review.md and repository conventions from CLAUDE.md