LCORE-175: Flatten data collection config

[onmete]

Description

Why

• Since the DataCollectorConfiguration parameter in start_data_collector is essentially unused (except for the enabled check), the separate class provides no real benefit.
• The current structure creates unnecessary complexity with config.user_data_collection.data_collector.enabled when it could just be config.user_data_collection.export_enabled.
• The supposed modular interface doesn't exist - the service always reads from the global config anyway.

How

• Flatten data collection configuration.
• Use configuration values to initialize DataCollectorService - detaching it from the rest of the code.

Needs rebase after #278

Type of change

• Refactor
• New feature
• Bug fix
• CVE fix
• Optimization
• Documentation Update
• Configuration Update
• Bump-up service version
• Bump-up dependent library
• Bump-up library or tool used for development (does not change the final image)
• CI configuration change
• Konflux configuration change
• Unit tests improvement
• Integration tests improvement
• End to end tests improvement

Related Tickets & Documents

• Related Issue #
• Closes #

Checklist before requesting a review

• I have performed a self-review of my code.
• PR has passed all pre-merge test jobs.
• If it is a core feature, I have added thorough tests.

Testing

• Please provide detailed steps to perform tests related to this code change.
• How were the fix/results from this change verified? Please provide relevant screenshots or results.

Summary by CodeRabbit

• Documentation

  • Updated configuration documentation to use a unified user data directory key, simplifying setup instructions.

• Refactor

  • Consolidated user data collection and export configuration into a single class for improved clarity and maintainability.
  • Updated internal services to use explicit configuration parameters instead of global objects.

• Bug Fixes

  • Improved validation for export configurations, ensuring all required fields are set when export is enabled.

• Tests

  • Updated and refactored tests to align with the new configuration structure and enhance test isolation.

[coderabbitai]

Walkthrough

This change consolidates separate feedback and transcript storage configurations into a unified user_data_dir key, refactors configuration and service code to use this new structure, and updates all relevant documentation and tests. The data collector service is modified to accept explicit parameters instead of relying on global configuration, and validation logic is updated accordingly.

Changes

File(s)	Change Summary
README.md, lightspeed-stack.yaml, tests/configuration/lightspeed-stack.yaml	Updated documentation and example configs to use user_data_dir instead of separate storage keys.
src/models/config.py	Unified feedback and transcript storage config into UserDataCollection, added properties, updated validation, removed/deprecated old classes.
src/runners/data_collector.py, src/services/data_collector.py, src/lightspeed_stack.py	Refactored to use new config structure, removed global config dependency in service, updated function signatures and instantiation.
src/app/endpoints/feedback.py, src/app/endpoints/query.py	Updated to use unified storage directory via new config properties.
tests/integration/test_configuration.py, tests/unit/app/endpoints/test_feedback.py, tests/unit/app/endpoints/test_query.py	Updated tests to use user_data_dir and new config structure, adjusted mocks and assertions.
tests/unit/models/test_config.py	Refactored tests for new config model, adjusted validation/error checks, updated JSON structure assertions.
tests/unit/runners/test_data_collector_runner.py	Updated to use new config class and naming, removed obsolete parameters.
tests/unit/services/test_data_collector.py	Refactored to remove global config mocks, added helper for service instantiation, improved test isolation and assertions.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant Endpoint (feedback/query)
    participant UserDataCollection (Config)
    participant DataCollectorService

    User->>Endpoint (feedback/query): Submit feedback/query
    Endpoint (feedback/query)->>UserDataCollection: Get feedback/transcript storage path
    UserDataCollection-->>Endpoint (feedback/query): Return path (from user_data_dir)
    Endpoint (feedback/query)->>FileSystem: Store feedback/transcript

    Note over DataCollectorService: Periodic collection
    DataCollectorService->>UserDataCollection: Get storage paths and export config
    DataCollectorService->>FileSystem: Collect files
    DataCollectorService->>RemoteServer: Send tarball (if export enabled)
    DataCollectorService->>FileSystem: Cleanup (if enabled)

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~40 minutes

Possibly related PRs

• LCORE-302: User Data Collection #237: Introduces the initial data collector feature and its configuration, which this PR directly refactors and builds upon by consolidating configuration and updating related usage.

Poem

🐇
In a burrow neat, I store my loot—
No more two paths, just one to boot!
Feedback and tales in one safe lair,
My configs are tidy, with room to spare.
I hop with joy, my code refined,
One data den, all paths aligned!
🌱

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bc6de6b and 1007cb0.

📒 Files selected for processing (15)

• README.md (3 hunks)
• lightspeed-stack.yaml (1 hunks)
• src/app/endpoints/feedback.py (1 hunks)
• src/app/endpoints/query.py (1 hunks)
• src/lightspeed_stack.py (1 hunks)
• src/models/config.py (1 hunks)
• src/runners/data_collector.py (1 hunks)
• src/services/data_collector.py (6 hunks)
• tests/configuration/lightspeed-stack.yaml (1 hunks)
• tests/integration/test_configuration.py (2 hunks)
• tests/unit/app/endpoints/test_feedback.py (2 hunks)
• tests/unit/app/endpoints/test_query.py (2 hunks)
• tests/unit/models/test_config.py (10 hunks)
• tests/unit/runners/test_data_collector_runner.py (3 hunks)
• tests/unit/services/test_data_collector.py (2 hunks)

🧰 Additional context used

🧠 Learnings (12)

📓 Common learnings

Learnt from: onmete
PR: lightspeed-core/lightspeed-stack#278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the `UserDataCollection.feedback_storage` property dynamically constructs paths from `user_data_dir` and will always return a valid string, making fallback logic like `or Path("")` redundant.

Learnt from: onmete
PR: lightspeed-core/lightspeed-stack#278
File: src/models/config.py:134-134
Timestamp: 2025-07-23T14:28:45.756Z
Learning: In the lightspeed-stack project, the `user_data_dir` field in `UserDataCollection` should remain as `str` type rather than `DirectoryPath` because the directory might not exist at configuration validation time and is only created later during runtime execution.

lightspeed-stack.yaml (2)

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

Learnt from: onmete
PR: #278
File: src/models/config.py:134-134
Timestamp: 2025-07-23T14:28:45.756Z
Learning: In the lightspeed-stack project, the user_data_dir field in UserDataCollection should remain as str type rather than DirectoryPath because the directory might not exist at configuration validation time and is only created later during runtime execution.

tests/integration/test_configuration.py (2)

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

Learnt from: onmete
PR: #278
File: src/models/config.py:134-134
Timestamp: 2025-07-23T14:28:45.756Z
Learning: In the lightspeed-stack project, the user_data_dir field in UserDataCollection should remain as str type rather than DirectoryPath because the directory might not exist at configuration validation time and is only created later during runtime execution.

tests/unit/app/endpoints/test_feedback.py (1)

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

src/app/endpoints/query.py (2)

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

Learnt from: onmete
PR: #278
File: src/models/config.py:134-134
Timestamp: 2025-07-23T14:28:45.756Z
Learning: In the lightspeed-stack project, the user_data_dir field in UserDataCollection should remain as str type rather than DirectoryPath because the directory might not exist at configuration validation time and is only created later during runtime execution.

src/app/endpoints/feedback.py (1)

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

src/lightspeed_stack.py (2)

Learnt from: onmete
PR: #278
File: src/models/config.py:134-134
Timestamp: 2025-07-23T14:28:45.756Z
Learning: In the lightspeed-stack project, the user_data_dir field in UserDataCollection should remain as str type rather than DirectoryPath because the directory might not exist at configuration validation time and is only created later during runtime execution.

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

README.md (1)

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

tests/configuration/lightspeed-stack.yaml (2)

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

Learnt from: onmete
PR: #278
File: src/models/config.py:134-134
Timestamp: 2025-07-23T14:28:45.756Z
Learning: In the lightspeed-stack project, the user_data_dir field in UserDataCollection should remain as str type rather than DirectoryPath because the directory might not exist at configuration validation time and is only created later during runtime execution.

tests/unit/app/endpoints/test_query.py (1)

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

src/models/config.py (2)

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

Learnt from: onmete
PR: #278
File: src/models/config.py:134-134
Timestamp: 2025-07-23T14:28:45.756Z
Learning: In the lightspeed-stack project, the user_data_dir field in UserDataCollection should remain as str type rather than DirectoryPath because the directory might not exist at configuration validation time and is only created later during runtime execution.

tests/unit/models/test_config.py (2)

Learnt from: onmete
PR: #278
File: src/app/endpoints/feedback.py:113-118
Timestamp: 2025-07-23T14:26:40.296Z
Learning: In the lightspeed-stack project after PR #278, the UserDataCollection.feedback_storage property dynamically constructs paths from user_data_dir and will always return a valid string, making fallback logic like or Path("") redundant.

Learnt from: onmete
PR: #278
File: src/models/config.py:134-134
Timestamp: 2025-07-23T14:28:45.756Z
Learning: In the lightspeed-stack project, the user_data_dir field in UserDataCollection should remain as str type rather than DirectoryPath because the directory might not exist at configuration validation time and is only created later during runtime execution.

🧬 Code Graph Analysis (10)

tests/integration/test_configuration.py (2)

src/models/config.py (1)

• feedback_storage (124-126)

tests/unit/test_configuration.py (2)

• test_load_configuration_with_customization_system_prompt_path (353-394)
• test_user_data_collection_configuration_not_loaded (317-323)

tests/unit/runners/test_data_collector_runner.py (2)

src/models/config.py (1)

• UserDataCollection (104-148)

src/runners/data_collector.py (1)

• start_data_collector (11-35)

src/app/endpoints/query.py (2)

src/configuration.py (2)

• configuration (47-52)
• user_data_collection_configuration (71-76)

src/models/config.py (1)

• transcripts_storage (129-131)

src/app/endpoints/feedback.py (3)

src/configuration.py (2)

• configuration (47-52)
• user_data_collection_configuration (71-76)

src/models/config.py (1)

• feedback_storage (124-126)

src/utils/suid.py (1)

• get_suid (6-12)

src/lightspeed_stack.py (2)

src/runners/data_collector.py (1)

• start_data_collector (11-35)

src/configuration.py (2)

• configuration (47-52)
• user_data_collection_configuration (71-76)

tests/unit/app/endpoints/test_query.py (1)

src/configuration.py (1)

• user_data_collection_configuration (71-76)

src/runners/data_collector.py (2)

src/models/config.py (3)

• UserDataCollection (104-148)
• feedback_storage (124-126)
• transcripts_storage (129-131)

src/services/data_collector.py (1)

• DataCollectorService (18-241)

src/models/config.py (1)

src/configuration.py (1)

• user_data_collection_configuration (71-76)

tests/unit/models/test_config.py (1)

src/models/config.py (3)

• UserDataCollection (104-148)
• feedback_storage (124-126)
• transcripts_storage (129-131)

tests/unit/services/test_data_collector.py (1)

src/services/data_collector.py (11)

• DataCollectorService (18-241)
• run (47-67)
• _collect_feedback_files (108-113)
• _collect_transcript_files (115-121)
• _perform_collection (69-106)
• _create_and_send_tarball (123-139)
• _create_tarball (141-166)
• _send_tarball (168-200)
• _cleanup_files (202-209)
• _cleanup_tarball (235-241)
• _cleanup_empty_directories (211-233)

🔇 Additional comments (37)

tests/configuration/lightspeed-stack.yaml (1)

20-20: Configuration refactor looks good.

The change from feedback_storage to user_data_dir correctly implements the flattening of the data collection configuration structure as described in the PR objectives.

lightspeed-stack.yaml (1)

21-21: Configuration consolidation implemented correctly.

The unified user_data_dir approach replaces the previous separate storage paths, successfully flattening the configuration structure.

src/lightspeed_stack.py (1)

82-82: Service initialization updated correctly.

The change from passing configuration.user_data_collection_configuration.data_collector to configuration.user_data_collection_configuration aligns with the removal of the nested DataCollectorConfiguration class and the flattening of the configuration structure.

tests/integration/test_configuration.py (2)

3-3: Import added for Path type.

The Path import is necessary since feedback_storage now returns a Path object instead of a string.

---

61-61: Test assertion updated correctly.

The assertion now correctly expects a Path object for feedback_storage, which validates that the property-based approach constructs the path as user_data_dir/feedback.

tests/unit/app/endpoints/test_feedback.py (3)

3-3: Path import added for updated configuration.

The Path import is required for setting user_data_dir as a Path object in the test setup.

---

101-101: Test configuration updated for new structure.

Setting user_data_dir instead of feedback_storage correctly reflects the new configuration approach where feedback_storage is a derived property.

---

104-105: Improved mocking strategy.

Patching mkdir directly on the Path class is cleaner and more targeted than the previous module-level patching approach.

tests/unit/runners/test_data_collector_runner.py (4)

5-5: LGTM: Import updated to reflect the unified configuration approach.

The import change from DataCollectorConfiguration to UserDataCollection aligns with the PR's objective to flatten the data collection configuration and eliminate the redundant separate class.

---

11-16: LGTM: Configuration parameters updated correctly.

The change from enabled to export_enabled provides better semantic clarity, and the removal of collection_interval from the test configuration aligns with the new approach where this parameter is passed explicitly to the DataCollectorService constructor.

---

26-31: LGTM: Consistent configuration updates in disabled test case.

The parameter updates maintain consistency with the first test case and correctly test the disabled state using export_enabled=False.

---

41-46: LGTM: Exception test case properly updated.

The configuration updates are consistent with the other test cases and correctly use export_enabled=True to ensure the service startup path is exercised before the exception is thrown.

README.md (2)

111-111: LGTM: Documentation correctly updated for unified storage configuration.

The change from separate feedback_storage and transcripts_storage paths to a single user_data_dir accurately reflects the new configuration structure and simplifies the user experience.

---

189-189: LGTM: Consistent documentation across all configuration examples.

The unified user_data_dir approach is consistently documented across both Llama Stack deployment scenarios, providing clear guidance to users.

src/app/endpoints/query.py (1)

353-354: LGTM: Redundant fallback logic correctly removed.

Based on the previous learning from PR #278, the UserDataCollection.transcripts_storage property dynamically constructs paths from user_data_dir and will always return a valid Path object, making the previous fallback logic unnecessary.

src/app/endpoints/feedback.py (1)

113-114: LGTM: Storage path handling simplified and improved.

The direct assignment from configuration.user_data_collection_configuration.feedback_storage is safe since the property always returns a valid Path object. The variable rename from storage_path to feedback_dir provides better semantic clarity.

Also applies to: 120-120

tests/unit/app/endpoints/test_query.py (2)

5-5: LGTM: Path import added for test configuration.

The import is necessary for creating the Path object used in the updated test configuration.

---

916-916: LGTM: Test configuration correctly updated for unified storage approach.

Setting user_data_dir = Path("/tmp") correctly results in transcripts_storage being /tmp/transcripts, which produces the expected final path in the assertion when combined with the user and conversation ID segments.

src/runners/data_collector.py (4)

5-5: LGTM! Import aligns with the flattened configuration structure.

The change from DataCollectorConfiguration to UserDataCollection properly reflects the consolidated configuration model.

---

11-11: LGTM! Function signature properly updated.

The parameter type change to UserDataCollection maintains consistency with the new configuration structure.

---

15-15: LGTM! More descriptive field name.

The change from enabled to export_enabled better describes the specific functionality being controlled.

---

20-29: Excellent refactoring to explicit dependency injection.

The change from implicit global configuration access to explicit parameter passing significantly improves:

• Testability by allowing easy mocking of dependencies
• Code clarity by making all dependencies visible
• Maintainability by decoupling the service from configuration structure

The use of feedback_storage and transcripts_storage properties aligns well with the unified configuration model.

src/services/data_collector.py (4)

17-17: Justified use of pylint disable.

The too-many-instance-attributes disable is appropriate here as the service legitimately needs all these configuration parameters to function properly.

---

25-46: Well-structured constructor with explicit dependencies.

The constructor properly initializes all required configuration as instance attributes. While the parameter count is high, each parameter serves a distinct purpose and the explicit nature improves testability and clarity.

---

56-59: Proper null handling for collection_interval.

Good defensive programming by checking if collection_interval is not None before sleeping.

---

91-99: Consistent refactoring throughout all methods.

All methods have been properly updated to use instance attributes instead of global configuration. The changes maintain the original logic while improving the design.

Also applies to: 110-121, 134-134, 172-192, 213-217

src/models/config.py (4)

104-111: Well-structured unified configuration model.

The consolidation of data collection and export settings into a single class with clear separation of concerns (collection vs export) improves configuration clarity.

---

110-110: Verify the use of Path type for user_data_dir.

According to previous learnings from PR #278, user_data_dir should be typed as str rather than Path because the directory might not exist at configuration validation time. Using Path type could cause validation failures.

Please verify that using Path type here won't cause issues during configuration validation when the directory doesn't exist. Consider reverting to str type as per the previous implementation.

---

123-131: Clean property implementation for storage paths.

The properties provide a clean interface for deriving storage paths from the base directory. This approach maintains consistency and reduces duplication.

---

133-148: Comprehensive validation with clear error messages.

The validation ensures all required export parameters are provided when export is enabled, with specific error messages for each missing field.

tests/unit/models/test_config.py (3)

136-141: LGTM! Tests properly verify default paths.

The test correctly verifies that the default user_data_dir and derived storage properties work as expected.

---

153-158: Excellent addition of custom directory test.

Good test coverage for verifying that custom user_data_dir paths properly propagate to the derived storage properties.

---

452-463: Properly updated JSON structure expectations.

The test correctly reflects the flattened configuration structure with all new export-related fields and their default values.

tests/unit/services/test_data_collector.py (4)

10-24: Excellent test helper design.

The _create_test_service helper function provides:

• Consistent default test values
• Easy override capability with kwargs
• Reduced test setup duplication
• Clear test intent

This significantly improves test maintainability.

---

26-33: Clean test setup with explicit assertions.

The test properly verifies service creation and initialization of all instance attributes.

---

208-235: Thorough testing of conditional cleanup behavior.

Excellent coverage of the cleanup_after_send flag behavior, ensuring cleanup methods are only called when appropriate and tarball cleanup always occurs.

---

78-85: Improved path mocking approach.

The direct patching of pathlib.Path methods (exists, glob, rglob) is cleaner and more focused than patching the entire Path class.

Also applies to: 100-108

✨ Finishing Touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Explain this complex logic.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai explain this code block.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai generate unit tests to generate unit tests for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[onmete]

I wouldn't worry about these changes.

The current data export is not working because content-type is passed as a header instead of a payload.
Also, it should consume just the provided user data dir from the other PR instead of checking data structure - I want to tackle this too.

Given these upcoming refactoring, I had two choices:

• comment all tests until I update the code and verify it works e2e
• let AI to fix the tests to pass

I decided for the second option.

[tisnik]

Don't we need to be prepared for other ways of sending transcripts? I don't think that sticking to Ingress would be the best solution (from config point of view)

[onmete]

closing