Update stale Drasi GitHub links

[Copilot]

• Remove Discussions link from README
• Re-run build to confirm status
• Reply to PR comment

Original prompt

---

This section details on the original issue you should resolve

<issue_title>url is 404</issue_title>
<issue_description>- DrasiLib - Core event processing engine

• Drasi - Main Drasi project</issue_description>

<agent_instructions>Search the repo for the two URLs contained in the original issue:

https://github.com/drasi-project/drasi-lib
https://github.com/drasi-project/drasi

These URLS do not exist anymore and need to be replaced with new ones. Here are the updated URLs:

https://github.com/drasi-project/drasi-lib -> https://github.com/drasi-project/drasi-core/tree/main/lib
https://github.com/drasi-project/drasi -> https://github.com/drasi-project

Specifically look in readme.md documents, code docs and comments, and workflow automation scripts.

Also, look for other URLs appearing in the repo and make a consolidated list of URLs for review.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes url is 404 #49

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[agentofreality]

@copilot the new URL is wrong. it should be https://github.com/drasi-project

[Copilot]

Updated the Drasi GitHub link to https://github.com/drasi-project and adjusted related references. Commit: a163943.

[agentofreality]

@copilot the new URL is wrong. it should be https://github.com/drasi-project

[Copilot]

Confirmed the Drasi project link is https://github.com/drasi-project; no further changes were needed. Commit: c363d7f.

[agentofreality]

@copilot this URL should be https://drasi.io/

[Copilot]

Updated the documentation link to https://drasi.io/. Commit: c363d7f.

[agentofreality]

@copilot delete this line, discussions are not enabled on the Drasi Server repo

[Copilot]

Removed the Discussions line from the README. Commit: 3cf7b68.

[github-actions]

YAML Configuration Validation Results

I've validated all YAML configuration snippets in markdown files against the Rust models. Found 2 critical issues in config/server-with-env-vars.yaml:

❌ Issue 1: Invalid field logLevel in Log Reaction (Line 86)

The LogReactionConfigDto struct only accepts routes and defaultTemplate fields. It has #[serde(deny_unknown_fields)] which will reject unknown fields.

Current (invalid):

reactions:
  - kind: log
    id: log-high-value-orders
    queries:
      - high-value-orders
    autoStart: true
    logLevel: "${REACTION_LOG_LEVEL:-info}"  # ❌ INVALID FIELD

Fix: Remove the logLevel field entirely.

---

❌ Issue 2: Invalid field method at top level of HTTP Reaction (Line 102)

The HttpReactionConfigDto struct doesn't accept method at the top level. The method field belongs inside the routes configuration.

Current (invalid):

reactions:
  - kind: http
    id: notify-high-value-orders
    queries:
      - high-value-orders
    autoStart: true
    baseUrl: "${WEBHOOK_URL}"
    method: POST  # ❌ INVALID - belongs in routes

Fix: Move method inside routes:

reactions:
  - kind: http
    id: notify-high-value-orders
    queries:
      - high-value-orders
    autoStart: true
    baseUrl: "${WEBHOOK_URL}"
    routes:
      high-value-orders:
        added:
          url: "/webhook"
          method: "POST"

---

⚠️ Issue 3: Bootstrap Provider with Extra Fields (Lines 50-55)

The postgres bootstrap provider in config/server-with-env-vars.yaml includes connection details that should not be there:

Current (invalid):

bootstrapProvider:
  kind: postgres
  host: "${DB_HOST}"          # ❌ Unknown field
  port: "${DB_PORT:-5432}"    # ❌ Unknown field  
  database: "${DB_NAME}"      # ❌ Unknown field
  user: "${DB_USER}"          # ❌ Unknown field
  password: "${DB_PASSWORD}"  # ❌ Unknown field

The PostgresBootstrapConfigDto is an empty struct - it uses the parent source's connection details automatically.

Fix:

bootstrapProvider:
  kind: postgres

---

✅ All Other Configs Valid

• README.md examples: All valid
• CLAUDE.md examples: All valid
• examples/getting-started/server-config.yaml: Valid
• examples/configs/ (all files): Valid
• tests/integration/getting-started/config.yaml: Valid

---

Field Naming Convention

All Rust models use #[serde(rename_all = "camelCase")]. Key examples:

✅ Correct	❌ Wrong
defaultTemplate	default_template
ssePath	sse_path
baseUrl	base_url
timeoutMs	timeout_ms
autoStart	auto_start

---

Expected Behavior: The server will fail to start with these config errors, reporting "unknown field" messages due to #[serde(deny_unknown_fields)] annotations on all DTO structs.

AI generated by YAML Snippet Validator

[github-actions]

YAML Configuration Validation Report

I validated all YAML configuration snippets in the markdown files against the Drasi Server's Rust models and found 1 issue that needs to be fixed.

---

❌ Issue Found

File: examples/configs/README.md
Line: 147
Severity: Error - Will cause runtime failure

Problem

bootstrapProvider:
  type: postgres  # ❌ WRONG - should be "kind"

Expected (based on Rust model)

bootstrapProvider:
  kind: postgres  # ✅ CORRECT

Root Cause

The bootstrap provider configuration uses a tagged enum with kind as the discriminator field. From src/api/models/bootstrap.rs:96:

#[derive(Debug, Clone, Serialize, PartialEq, ToSchema)]
#[serde(tag = "kind", rename_all = "lowercase")]
pub enum BootstrapProviderConfig {
    Postgres(PostgresBootstrapConfigDto),
    // ...
}

The #[serde(tag = "kind")] attribute means the deserializer expects kind, not type.

Impact

• Users copying this example will get a deserialization error: missing field 'kind'
• The server will fail to start with this configuration

Suggested Fix

Change line 147 in examples/configs/README.md from:

-      type: postgres
+      kind: postgres

---

✅ All Other Snippets Validated Successfully

I validated 32 YAML snippets across:

• README.md (26 snippets)
• CLAUDE.md (2 snippets)
• examples/configs/README.md (reference docs)
• All examples/configs/**/*.yaml files

Key findings:

• ✅ All actual config files in examples/configs/ use the correct kind field
• ✅ README.md and CLAUDE.md are correct throughout
• ✅ The issue exists ONLY in the reference documentation in examples/configs/README.md line 147

---

Validation Methodology

1. Rust Model Analysis: Examined all DTO structs in src/api/models/ to understand field names, required vs optional fields, and enum discriminators
2. YAML Extraction: Extracted all YAML code blocks from markdown files
3. Schema Validation: Compared YAML field names against Rust struct field names with camelCase transformation
4. Cross-Reference: Verified working example files use correct field names

---

Recommendations

1. ✅ Fix the typo in examples/configs/README.md line 147 (change type: to kind:)
2. 💡 Consider adding automated validation that parses markdown YAML snippets and validates them against Rust deserializers in CI/CD
3. 💡 Add schema validation command like drasi-server validate --config for users

AI generated by YAML Snippet Validator

[github-actions]

YAML Configuration Snippet Validation Report

Summary

✅ Validated all YAML configuration snippets across repository markdown files against Rust models and runtime behavior.

Result: Found 2 field naming inconsistencies in tutorial documentation. The YAML examples use incorrect snake_case field names instead of the required camelCase format.

---

Issues Found

Issue #1: default_template should be defaultTemplate

Location: examples/getting-started/README.md line 266

Problem:

reactions:
  - kind: log
    id: log-all-queries
    default_template:  # ❌ WRONG
      added:
        template: "[{{query_name}}] + {{after}}"

Fix Required:

reactions:
  - kind: log
    id: log-all-queries
    defaultTemplate:  # ✅ CORRECT
      added:
        template: "[{{query_name}}] + {{after}}"

Root Cause:

• LogReactionConfigDto (src/api/models/reactions/log.rs:46) uses #[serde(rename_all = "camelCase")]
• Field default_template in Rust serializes to defaultTemplate in YAML
• Working configs use defaultTemplate (e.g., examples/getting-started/server-config.yaml:141)

Runtime Impact:

Error: unknown field `default_template`, expected `routes` or `defaultTemplate`

---

Issue #2: sse_path should be ssePath

Location: examples/getting-started/README.md line 288

Problem:

  - kind: sse
    id: sse-stream
    sse_path: /events  # ❌ WRONG

Fix Required:

  - kind: sse
    id: sse-stream
    ssePath: /events  # ✅ CORRECT

Root Cause:

• SseReactionConfigDto (src/api/models/reactions/sse.rs:50) uses #[serde(rename_all = "camelCase")]
• Field sse_path in Rust serializes to ssePath in YAML
• Working configs use ssePath (e.g., examples/getting-started/server-config.yaml:161)

Runtime Impact:

Error: unknown field `sse_path`, expected one of `host`, `port`, `ssePath`, `heartbeatIntervalMs`, ...

---

Verification Status

✅ Correct naming confirmed in:

• Main README.md (uses camelCase)
• examples/getting-started/server-config.yaml (working config)
• examples/configs/**/*.yaml (all example configs)
• examples/configs/README.md

❌ Incorrect naming found in:

• examples/getting-started/README.md (tutorial documentation only)

All other YAML snippets in documentation match the Rust models correctly.

---

Impact Assessment

Severity: Medium

• Users following the tutorial will copy broken YAML
• Server fails to start with cryptic deserialization errors
• Due to #[serde(deny_unknown_fields)], misspelled fields cause immediate failure

Affected Users:

• New users following the getting-started tutorial
• Anyone copy-pasting from tutorial docs instead of working config files

---

Recommendation

Update examples/getting-started/README.md to use camelCase field names:

• Line 266: default_template → defaultTemplate
• Line 288: sse_path → ssePath

This matches the Rust models, working configuration files, and all other documentation.

AI generated by YAML Snippet Validator

[github-actions]

YAML Configuration Validation Report

I've validated all YAML configuration snippets in markdown files against the Drasi Server's Rust models.

✅ Overall Status: Good

The YAML configurations in the repository are well-structured and mostly correct. Field names use proper camelCase formatting as expected by the Rust serde models, and the actual .yaml config files in config/ and examples/configs/ are all valid.

⚠️ Issue Found: Documentation Inconsistency

Location: README.md line 468

Problem: The documentation states that autoStart defaults to true for queries:

| `autoStart` | boolean | `true` | Start query automatically |

Reality: According to the Rust code (src/api/models/queries/query.rs lines 63-65), the default is actually false:

fn default_auto_start() -> bool {
    false
}

Impact:

• Users who omit autoStart from query configurations will find their queries don't start automatically
• This differs from sources and reactions, which both default to true

Suggested Fix: Update README.md line 468 to:

| `autoStart` | boolean | `false` | Start query automatically |

✅ Validation Summary

Checked Components:

• ✅ Server configuration fields (all camelCase as expected)
• ✅ Source configurations (mock, http, grpc, postgres, platform)
• ✅ Query configurations
• ✅ Reaction configurations (log, http, sse, grpc, profiler, platform)
• ✅ Multi-instance configurations
• ✅ State store configurations
• ✅ Bootstrap provider configurations

Default Values Verified:

• ✅ Sources: autoStart defaults to true ✓
• ✅ Reactions: autoStart defaults to true ✓
• ⚠️ Queries: autoStart defaults to false (documentation says true)

Files Validated:

• ✅ README.md - YAML snippets are valid
• ✅ CLAUDE.md - YAML snippets are valid
• ✅ examples/configs/README.md - YAML snippets are valid
• ✅ config/server-minimal.yaml - Valid
• ✅ config/server-docker.yaml - Valid
• ✅ All example configs in examples/configs/*/ - All valid

📝 Notes

1. Field Naming: All structs correctly use #[serde(rename_all = "camelCase")], and the documentation consistently uses camelCase field names (e.g., autoStart, queryLanguage, sourceId, logLevel, persistConfig, etc.)

2. Runtime Validation: Unable to perform runtime validation due to permission restrictions in the environment, but static analysis against Rust models shows all configs are structurally valid.

3. No Other Issues Found: All other YAML snippets match the expected schema perfectly.

AI generated by YAML Snippet Validator

[github-actions]

✅ YAML Snippet Validation Complete

I've validated all YAML configuration snippets in markdown files against the Drasi Server's Rust models and existing test infrastructure.

Summary

All YAML snippets are valid! ✨

The repository has excellent test coverage for YAML configuration validation:

1. tests/readme_examples_validation_test.rs - Validates all YAML code blocks in README.md
2. tests/example_configs_validation_test.rs - Validates 25+ example config files

Validation Coverage

Markdown files with YAML snippets:

• ✅ README.md (27 YAML blocks) - Fully validated by test suite
• ✅ CLAUDE.md (2 YAML blocks) - Configuration examples match Rust models
• ✅ DOCKER.md (1 YAML block) - Environment variable usage example
• ✅ examples/configs/README.md (4 YAML blocks) - Schema reference examples
• ✅ examples/getting-started/README.md (3 YAML blocks) - Tutorial examples
• ✅ tests/README.md (1 YAML block) - Test configuration
• ✅ tests/integration/getting-started/README.md (1 YAML block)

Schema Validation Findings

All YAML snippets correctly use camelCase field names as required by the Rust DTOs:

Field in Rust (snake_case)	YAML (camelCase)	Status
auto_start	autoStart	✅ Correct
query_language	queryLanguage	✅ Correct
enable_bootstrap	enableBootstrap	✅ Correct
bootstrap_buffer_size	bootstrapBufferSize	✅ Correct
source_id	sourceId	✅ Correct
slot_name	slotName	✅ Correct
publication_name	publicationName	✅ Correct
table_keys	tableKeys	✅ Correct
key_columns	keyColumns	✅ Correct
ssl_mode	sslMode	✅ Correct
data_type	dataType	✅ Correct
interval_ms	intervalMs	✅ Correct
timeout_ms	timeoutMs	✅ Correct
persist_config	persistConfig	✅ Correct
persist_index	persistIndex	✅ Correct
log_level	logLevel	✅ Correct
state_store	stateStore	✅ Correct

Test Infrastructure

The existing test suite provides comprehensive validation:

// tests/readme_examples_validation_test.rs
- test_readme_yaml_blocks_are_valid_yaml() - Validates YAML syntax
- test_readme_complete_configs_validate() - Validates against Rust models
- test_readme_minimal_config_example() - Specific example validation
- test_readme_server_settings_example() - Server settings validation

// tests/example_configs_validation_test.rs  
- test_all_example_configs_are_valid() - Validates 25+ config files
- Individual tests for each config file (granular validation)

Example Config Files Validated

All 25+ example configuration files pass validation:

• ✅ config/server-minimal.yaml
• ✅ config/server-docker.yaml
• ✅ config/server-with-env-vars.yaml
• ✅ examples/getting-started/server-config.yaml
• ✅ examples/configs/01-fundamentals/hello-world.yaml
• ✅ examples/configs/02-sources/*.yaml (3 files)
• ✅ examples/configs/03-reactions/*.yaml (5 files)
• ✅ examples/configs/04-query-patterns/*.yaml (4 files)
• ✅ examples/configs/05-advanced-features/*.yaml (5 files)
• ✅ examples/configs/06-real-world-scenarios/*.yaml (4 files)

Recommendations

1. Continue running existing tests - The current test suite is comprehensive and catches schema mismatches
2. CI/CD integration - Tests run automatically on PRs via .github/workflows/test.yml
3. Documentation fragments - Incomplete YAML snippets in documentation are correctly identified as fragments by the test logic

Technical Details

The validation leverages Rust's serde with #[serde(rename_all = "camelCase")] on all DTOs:

• QueryConfigDto in src/api/models/queries/query.rs
• PostgresSourceConfigDto in src/api/models/sources/postgres.rs
• MockSourceConfigDto in src/api/models/sources/mock.rs
• All reaction DTOs in src/api/models/reactions/

This ensures YAML field names automatically map to Rust struct fields via serde deserialization.

---

No action required - All YAML snippets are valid and properly tested! 🎉

AI generated by YAML Snippet Validator