-
Notifications
You must be signed in to change notification settings - Fork 10
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
add lisitng olap operation to the implementation basic reality checker working base implementation of reality checker added ability to read from redis seems to be mostly working working ish implementation some fixes fixes fix arnings fix clippy fix tests fix comment remove some breaking changes revert back fix revert some code changes
- Loading branch information
Showing
22 changed files
with
2,481 additions
and
99 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
--- | ||
description: Best practices to edit and build .proto files | ||
globs: *.proto | ||
--- | ||
|
||
DO NOT MAKE BREAKING CHANGES |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,104 @@ | ||
--- | ||
description: Rust Langauge best practices | ||
globs: *.rs | ||
--- | ||
# Architectural Rules | ||
|
||
## General Principles | ||
|
||
- **Keep it Simple (KISS)**: Strive for simplicity in code design. | ||
- **Don't Repeat Yourself (DRY)**: Eliminate duplication to enhance maintainability. | ||
- **You Ain't Gonna Need It (YAGNI)**: Avoid adding functionality until it's necessary. | ||
- **Readability Matters**: Write code as if the next person to read it is a beginner. | ||
|
||
## Code Structure | ||
|
||
- Use meaningful and descriptive variable, function, and class names. | ||
- Organize files and directories logically. | ||
- Follow a consistent indentation and formatting style (use linters and formatters). | ||
- Separate concerns: Keep logic modular and avoid monolithic functions. | ||
|
||
## Performance Considerations | ||
|
||
- Optimize only when necessary—write clear code first. | ||
- Use efficient data structures and algorithms. | ||
- Avoid unnecessary computations and redundant API calls. | ||
- Be mindful of memory usage and garbage collection. | ||
|
||
## Security Best Practices | ||
|
||
- Never hardcode sensitive data (use environment variables or secrets management tools). | ||
- Sanitize inputs to prevent injection attacks. | ||
- Follow the principle of least privilege when managing permissions. | ||
- Keep dependencies updated to mitigate vulnerabilities. | ||
|
||
|
||
|
||
## Error Handling | ||
1. Error types should be located near their unit of fallibility | ||
- No global `Error` type or `errors.rs` module | ||
- Each module/component defines its own error types | ||
- Error types live close to the functions that generate them | ||
|
||
2. Use thiserror for error definitions | ||
- Derive Error trait using #[derive(thiserror::Error)] | ||
- Use #[error()] attribute for human-readable messages | ||
- Use #[from] attribute to implement From trait where appropriate | ||
- Mark error types as #[non_exhaustive] | ||
|
||
3. Structure errors in layers | ||
- Use struct for context (e.g. file paths, line numbers) | ||
- Use enum for error variants | ||
- Implement source() to chain underlying errors | ||
- Example: | ||
```rust | ||
#[derive(Debug, thiserror::Error)] | ||
#[error("error reading `{path}`")] | ||
pub struct FileError { | ||
pub path: PathBuf, | ||
#[source] | ||
pub kind: FileErrorKind | ||
} | ||
``` | ||
|
||
4. Error matching and handling | ||
- Make errors inspectable with specific variants | ||
- Provide enough context for actionable error messages | ||
- Use meaningful variant names (e.g. ReadFile vs Io) | ||
- Document error conditions and handling | ||
|
||
5. Error stability and privacy | ||
- Consider making error fields private when needed | ||
- Don't expose internal error types in public API | ||
- Use opaque error types for stable interfaces | ||
- Version error types appropriately | ||
|
||
6. Do NOT use anyhow::Result | ||
- If you see anyhow::Result being used, refactor using this::error | ||
|
||
## Constants | ||
- Use `const` for all static values in Rust unless interior mutability or runtime evaluation is required. | ||
- Prefer placing constants in a `constants.rs` file. | ||
- The `constants.rs` file should be located at the deepest level in the module tree but at the highest level where all usages of the constants exist. | ||
- Ensure constants are appropriately scoped to avoid unnecessary exposure to unrelated modules. | ||
- Use `pub(crate)` or `pub(super)` instead of `pub` when limiting visibility to the necessary scope. | ||
- Group related constants together for better maintainability and readability. | ||
- Use descriptive names in uppercase with underscores (e.g., `MAX_RETRY_COUNT`). | ||
- When working with enums or complex types, prefer `static` with `lazy_static!` or `once_cell::sync::Lazy` for initialization. | ||
- Avoid redefining constants in multiple places; ensure they are sourced from `constants.rs` where needed. | ||
|
||
## Documentation | ||
1. All public APIs must be documented | ||
2. Architecture decisions should be documented | ||
3. Side effects should be clearly documented | ||
4. Breaking changes must be documented | ||
|
||
## Observability | ||
|
||
- Implement logging, metrics, and tracing to gain insights into system behavior. | ||
- Use structured logging for better searchability and debugging. | ||
- Leverage distributed tracing to diagnose performance bottlenecks in microservices. | ||
|
||
## Linters | ||
* Always run `cargo clippy` to make sure your changes are right. In Clippy we trust. | ||
* Don't go around the linters by adding exceptions, try to actually use the variables if you find deadcode or delete the code if it is actually not useful. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.