-
Notifications
You must be signed in to change notification settings - Fork 6
chore: update readme file #53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… all related namespaces
…ding unique id in the filename
…ve generated token to redis
WalkthroughThis update migrates the project from "DocumentService" to "OsmoDoc," renaming namespaces, classes, documentation, and configuration files accordingly. It introduces Redis-backed JWT token management, adds new API endpoints for login and token revocation, and restructures Docker and environment setups. Both PDF and Word document generation logic are refactored, with improved configuration, validation, and asynchronous processing. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API as OsmoDoc.API
participant Redis
participant PDFGen as PdfDocumentGenerator
participant WordGen as WordDocumentGenerator
Client->>API: POST /api/login (email)
API->>API: Generate JWT token
API->>Redis: StoreTokenAsync(token, email)
Redis-->>API: Ack
API-->>Client: { status: Success, token }
Client->>API: POST /api/revoke (token)
API->>Redis: RevokeTokenAsync(token)
Redis-->>API: Ack
API-->>Client: { status: Success }
Client->>API: POST /api/pdf (PDFGenerationRequestDTO)
API->>PDFGen: GeneratePdf(template, metaData, ...)
PDFGen-->>API: PDF file path
API-->>Client: { status: Success, file }
Client->>API: POST /api/word (WordGenerationRequestDTO)
API->>WordGen: GenerateDocumentByTemplate(template, data, ...)
WordGen-->>API: Word file path
API-->>Client: { status: Success, file }
Poem
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed 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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 9
🧹 Nitpick comments (20)
.github/PULL_REQUEST_TEMPLATE/pull_request_template_api.md (1)
68-71: Replace stray replacement characters with normal bulletsThe “�” glyphs indicate a bad copy-paste / encoding issue and render oddly in Markdown.
- - <strong style="color:black">�</strong> **If we suggest changes, then:** - - � Make the required updates. - - � Ensure that your changes do not break existing functionality or introduce new issues. - - � Rebase your branch and force push to your GitHub repository. This will update your Pull Request. + - **If we suggest changes, then:** + - Make the required updates. + - Ensure that your changes do not break existing functionality or introduce new issues. + - Rebase your branch and force-push to update the PR.CONTRIBUTING.md (1)
1-2: Unify brand capitalization: “OsmoDoc” vs “osmodoc”Line 1 introduces “OsmoDoc” (PascalCase) while line 2 immediately switches to lowercase “osmodoc”.
Standardising on a single style improves brand consistency across docs.OsmoDoc.API/Helpers/Base64StringHelper.cs (1)
5-17: Harden input & avoid silent overwrite
configuration.GetSection("CONFIG:UPLOAD_FILE_SIZE_LIMIT_BYTES").Valuecan returnnull, causingConvert.ToInt64to throw.File.WriteAllBytesAsyncwill blindly overwrite an existing file.+ if (configuration is null) + throw new ArgumentNullException(nameof(configuration)); + + var sizeLimitValue = configuration["CONFIG:UPLOAD_FILE_SIZE_LIMIT_BYTES"]; + if (!long.TryParse(sizeLimitValue, out var uploadFileSizeLimitBytes)) + throw new InvalidOperationException("Missing/invalid upload size limit config."); + - long uploadFileSizeLimitBytes = Convert.ToInt64(configuration.GetSection("CONFIG:UPLOAD_FILE_SIZE_LIMIT_BYTES").Value); - - if (data.LongLength > uploadFileSizeLimitBytes) + if (data.LongLength > uploadFileSizeLimitBytes) throw new BadHttpRequestException("Uploaded file is too large"); + + // Fail if the file already exists to avoid accidental overwrite + if (File.Exists(filePath)) + throw new IOException($"File already exists at {filePath}");Consider also streaming to disk instead of buffering the entire byte[] for very large uploads, but that might be outside this PR’s scope.
OsmoDoc.API/DotEnv.cs (1)
12-30: Skip empty / comment lines & tighten parsing for robustness
Loadcurrently processes every non-existent/blank line and ignores#comment lines only if they don’t contain=.
This will:
- Try to set env-vars for lines that are whitespace only.
- Mis-handle commented keys like
#FOO=bar(will set an empty key).A small guard and using the newer range syntax keeps the method safe & compact:
foreach (string raw in File.ReadAllLines(filePath)) { - // Check if the line contains '=' - int equalsIndex = line.IndexOf('='); - if (equalsIndex == -1) - { - continue; // Skip lines without '=' - } + var line = raw.Trim(); + if (string.IsNullOrEmpty(line) || line.StartsWith('#')) + continue; + + var equalsIndex = line.IndexOf('='); + if (equalsIndex <= 0) // key cannot be empty + continue; string key = line[..equalsIndex].Trim(); - string value = line.Substring(equalsIndex + 1).Trim(); + string value = line[(equalsIndex + 1)..].Trim(); // Remove the surrounding quotes, if any - if (value.StartsWith("\"") && value.EndsWith("\"")) - { - value = value[1..^1]; - } + if (value.Length > 1 && value.StartsWith('"') && value.EndsWith('"')) + value = value[1..^1]; Environment.SetEnvironmentVariable(key, value); }No behavioural change for valid lines, but prevents accidental bad keys and unnecessary env-var writes.
OsmoDoc/Pdf/Models/ContentMetaData.cs (1)
3-7: Consider record type & XML docs for public modelThis DTO is immutable in practice and exposed publicly. A C#
record(orrecord class) gives:
- built-in value equality (useful in unit tests)
- succinct syntax
-public class ContentMetaData -{ - public string Placeholder { get; set; } = string.Empty; - public string Content { get; set; } = string.Empty; -} +/// <summary> +/// Mapping between a template placeholder and its replacement content. +/// </summary> +public record ContentMetaData(string Placeholder, string Content);Purely optional, but reduces boilerplate and communicates intent.
OsmoDoc/Pdf/Models/DocumentData.cs (2)
1-4: Remove unusedSystem.Textimport.
System.Textisn’t referenced – keeping it adds noise and may trigger style-cop warnings.-using System.Text;
7-10: Add XML docs & prefer collection expression.To keep parity with the Word counterpart and surface-area docs:
-namespace OsmoDoc.Pdf.Models; - -public class DocumentData -{ - public List<ContentMetaData> Placeholders { get; set; } = new List<ContentMetaData>(); -} +namespace OsmoDoc.Pdf.Models; + +/// <summary> +/// Represents the placeholder data for PDF generation. +/// </summary> +public class DocumentData +{ + /// <summary> + /// List of placeholder metadata. Empty list is allowed. + /// </summary> + public List<ContentMetaData> Placeholders { get; set; } = new(); +}OsmoDoc.API/Helpers/AuthenticationHelper.cs (1)
10-27: Parameter naming & null-input guard.Minor polish – makes the public surface more idiomatic and avoids silent NREs:
-public static string JwtTokenGenerator(string LoginEmail) +public static string JwtTokenGenerator(string loginEmail) { - SymmetricSecurityKey secretKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes( + ArgumentNullException.ThrowIfNull(loginEmail); + + var secretKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes( Environment.GetEnvironmentVariable("JWT_KEY") ?? throw new InvalidOperationException("No JWT key specified") )); - SigningCredentials signinCredentials = new SigningCredentials(secretKey, SecurityAlgorithms.HmacSha256); + var signinCredentials = new SigningCredentials(secretKey, SecurityAlgorithms.HmacSha256);(Safe to defer if outside PR scope; creating a tracking issue would match past preference.)
OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs (1)
5-6: Consider locking-in configuration immutability
WkhtmltopdfPathis a mutable static. If this value is changed after services are already using it, concurrent requests could see inconsistent paths. If runtime changes aren’t required, make the setterinit-only (C# 9) or expose a one-timeConfiguremethod that throws if called twice.- public static string? WkhtmltopdfPath { get; set; } + public static string? WkhtmltopdfPath { get; init; }OsmoDoc/Word/Models/ContentData.cs (1)
7-29: Fix documentation inconsistency regarding content types.The class implementation is solid with proper initialization and comprehensive documentation. However, there's an inconsistency on line 20 where the comment mentions "text or image" but the
ContentTypeenum only supportsText.Apply this fix to align the documentation with the current enum:
/// <summary> - /// Gets or sets the content type of the placeholder (text or image). + /// Gets or sets the content type of the placeholder. /// </summary>OsmoDoc/Word/Models/DocumentData.cs (1)
1-3: Remove unused using statements.The
SystemandSystem.Textnamespaces are not used in this file.Apply this diff to remove unused imports:
-using System; using System.Collections.Generic; -using System.Text;OsmoDoc.API/Models/WordGenerationRequestDTO.cs (1)
17-19: Consider using consistent list initialization syntax.For consistency with modern C# syntax, consider using just
new()instead ofnew List<T>():- public List<ContentData> Placeholders { get; set; } = new List<ContentData>(); - public List<TableData> TablesData { get; set; } = new List<TableData>(); - public List<ImageData> ImagesData { get; set; } = new List<ImageData>(); + public List<ContentData> Placeholders { get; set; } = new(); + public List<TableData> TablesData { get; set; } = new(); + public List<ImageData> ImagesData { get; set; } = new();OsmoDoc/Services/RedisTokenStoreService.cs (1)
24-28: Consider using System.Text.Json for better performance.Since this is new code, consider using the more performant
System.Text.Jsoninstead ofNewtonsoft.Json:-using Newtonsoft.Json; +using System.Text.Json; - return this._db.StringSetAsync($"{KeyPrefix}{token}", JsonConvert.SerializeObject(new + return this._db.StringSetAsync($"{KeyPrefix}{token}", JsonSerializer.Serialize(new { issuedTo = email, issuedAt = DateTime.UtcNow }));Dockerfile (1)
17-20: Consider adding .dockerignore for build optimization.While copying entire directories simplifies the Dockerfile, it may include unnecessary files in the build context. Consider creating a
.dockerignorefile to exclude files likebin/,obj/, and other build artifacts.Would you like me to generate a
.dockerignorefile to optimize the Docker build process?OsmoDoc.API/Program.cs (1)
39-43: Consider validating the wkhtmltopdf tool path at startup.The PDF tool path is set but not validated. Consider checking if the file exists at startup to fail fast if misconfigured.
Add validation after setting the path:
OsmoDocPdfConfig.WkhtmltopdfPath = Path.Combine( builder.Environment.WebRootPath, builder.Configuration.GetSection("STATIC_FILE_PATHS:HTML_TO_PDF_TOOL").Value! ); + +// Validate tool path on non-Linux platforms +if (!RuntimeInformation.IsOSPlatform(OSPlatform.Linux) && !File.Exists(OsmoDocPdfConfig.WkhtmltopdfPath)) +{ + throw new FileNotFoundException($"wkhtmltopdf tool not found at: {OsmoDocPdfConfig.WkhtmltopdfPath}"); +}OsmoDoc.API/Controllers/LoginController.cs (1)
25-31: Add email validation in the login endpoint.The login endpoint accepts an email but doesn't validate its format. Consider adding email validation to prevent invalid tokens from being generated.
Add validation before generating the token:
public async Task<ActionResult<BaseResponse>> Login([FromBody] LoginRequestDTO loginRequest) { BaseResponse response = new BaseResponse(ResponseStatus.Fail); try { + if (string.IsNullOrWhiteSpace(loginRequest?.Email)) + { + response.Message = "Email is required"; + return this.BadRequest(response); + } + + // Optional: Add email format validation + if (!System.ComponentModel.DataAnnotations.EmailAddressAttribute().IsValid(loginRequest.Email)) + { + response.Message = "Invalid email format"; + return this.BadRequest(response); + } + string token = AuthenticationHelper.JwtTokenGenerator(loginRequest.Email); await this._tokenStoreService.StoreTokenAsync(token, loginRequest.Email, this.HttpContext.RequestAborted);README.md (3)
30-30: Add missing article "a" for better grammar.-6. Copy data from [example template](.env.example) into `.env`. Then set suitable JWT key. +6. Copy data from [example template](.env.example) into `.env`. Then set a suitable JWT key.
33-33: Fix heading hierarchy for proper document structure.The heading levels jump from h2 to h4, skipping h3. This affects document structure and accessibility.
-#### Development +### Development-#### Testing/Staging +### Testing/Staging-#### Production +### Production-#### HTML TO PDF +### HTML TO PDF-#### EJS TO PDF +### EJS TO PDFAlso applies to: 112-112
260-260: Clarify the target framework specification.The framework is listed as ".NET Framework 8.0", but .NET 8.0 is part of the modern .NET (formerly .NET Core) lineup, not .NET Framework.
-1. .NET Framework 8.0 +1. .NET 8.0docker-compose.yaml (1)
32-32: Add newline at end of file.Add a newline character at the end of the file to follow YAML best practices:
osmodoc-net: - driver: bridge + driver: bridge +
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
OsmoDoc.API/wwwroot/Tools/wkhtmltopdf.exeis excluded by!**/*.exe
📒 Files selected for processing (60)
.env.example(1 hunks).github/PULL_REQUEST_TEMPLATE/pull_request_template_api.md(1 hunks).gitignore(1 hunks)CONTRIBUTING.md(7 hunks)Dockerfile(1 hunks)DocumentService.API/Helpers/AutoMappingProfile.cs(0 hunks)DocumentService.API/Models/PdfGenerationRequestDTO.cs(0 hunks)DocumentService.API/Models/WordGenerationRequestDTO.cs(0 hunks)DocumentService/DocumentService.csproj(0 hunks)DocumentService/Pdf/Models/ContentMetaData.cs(0 hunks)DocumentService/Pdf/Models/DocumentData.cs(0 hunks)DocumentService/Pdf/PdfDocumentGenerator.cs(0 hunks)DocumentService/Word/Models/ContentData.cs(0 hunks)DocumentService/Word/Models/DocumentData.cs(0 hunks)DocumentService/Word/Models/Enums.cs(0 hunks)DocumentService/Word/Models/TableData.cs(0 hunks)DocumentService/Word/WordDocumentGenerator.cs(0 hunks)OsmoDoc.API/Controllers/LoginController.cs(1 hunks)OsmoDoc.API/Controllers/PdfController.cs(1 hunks)OsmoDoc.API/Controllers/WordController.cs(1 hunks)OsmoDoc.API/DotEnv.cs(1 hunks)OsmoDoc.API/Helpers/AuthenticationHelper.cs(1 hunks)OsmoDoc.API/Helpers/AutoMappingProfile.cs(1 hunks)OsmoDoc.API/Helpers/Base64StringHelper.cs(1 hunks)OsmoDoc.API/Helpers/CommonMethodsHelper.cs(1 hunks)OsmoDoc.API/Models/BaseResponse.cs(1 hunks)OsmoDoc.API/Models/LoginRequestDTO.cs(1 hunks)OsmoDoc.API/Models/PdfGenerationRequestDTO.cs(1 hunks)OsmoDoc.API/Models/RevokeTokenRequestDTO.cs(1 hunks)OsmoDoc.API/Models/WordGenerationRequestDTO.cs(1 hunks)OsmoDoc.API/OsmoDoc.API.csproj(1 hunks)OsmoDoc.API/OsmoDoc.API.sln(1 hunks)OsmoDoc.API/Program.cs(1 hunks)OsmoDoc.sln(1 hunks)OsmoDoc/OsmoDoc.csproj(1 hunks)OsmoDoc/Pdf/Models/ContentMetaData.cs(1 hunks)OsmoDoc/Pdf/Models/DocumentData.cs(1 hunks)OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs(1 hunks)OsmoDoc/Pdf/PdfDocumentGenerator.cs(1 hunks)OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs(1 hunks)OsmoDoc/Services/RedisTokenStoreService.cs(1 hunks)OsmoDoc/Word/Models/ContentData.cs(1 hunks)OsmoDoc/Word/Models/DocumentData.cs(1 hunks)OsmoDoc/Word/Models/Enums.cs(1 hunks)OsmoDoc/Word/Models/ImageData.cs(1 hunks)OsmoDoc/Word/Models/TableData.cs(1 hunks)OsmoDoc/Word/WordDocumentGenerator.cs(1 hunks)README.md(3 hunks)docker-compose.yaml(1 hunks)docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentData.html(5 hunks)docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentType.html(2 hunks)docs/site/10.0.2/api/OsmoDoc.Word.Models.DocumentData.html(4 hunks)docs/site/10.0.2/api/OsmoDoc.Word.Models.ParentBody.html(2 hunks)docs/site/10.0.2/api/OsmoDoc.Word.Models.TableData.html(3 hunks)docs/site/10.0.2/api/OsmoDoc.Word.Models.html(2 hunks)docs/site/10.0.2/api/OsmoDoc.Word.WordDocumentGenerator.html(3 hunks)docs/site/10.0.2/api/OsmoDocWord.html(2 hunks)docs/site/10.0.2/api/toc.html(1 hunks)docs/site/manifest.json(1 hunks)docs/site/xrefmap.yml(1 hunks)
💤 Files with no reviewable changes (12)
- DocumentService.API/Helpers/AutoMappingProfile.cs
- DocumentService/Pdf/Models/DocumentData.cs
- DocumentService/Word/Models/ContentData.cs
- DocumentService/Word/Models/TableData.cs
- DocumentService/Word/Models/DocumentData.cs
- DocumentService/Pdf/Models/ContentMetaData.cs
- DocumentService/DocumentService.csproj
- DocumentService/Word/Models/Enums.cs
- DocumentService.API/Models/WordGenerationRequestDTO.cs
- DocumentService.API/Models/PdfGenerationRequestDTO.cs
- DocumentService/Word/WordDocumentGenerator.cs
- DocumentService/Pdf/PdfDocumentGenerator.cs
🧰 Additional context used
🧠 Learnings (46)
📓 Common learnings
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:3-7
Timestamp: 2025-07-04T03:19:33.236Z
Learning: osm-Jatin prefers to defer non-critical code improvements like thread safety enhancements and validation logic when they are not essential for the current PR scope, preferring to keep changes focused on the main objectives.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:96-97
Timestamp: 2025-07-04T03:27:39.798Z
Learning: osm-Jatin prefers to defer security-related logging improvements (like removing stack trace logging) when they are not essential for the current PR scope in the OsmoDoc project, choosing to keep existing implementation for now.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/RedisTokenStoreService.cs:18-24
Timestamp: 2025-06-20T14:36:49.953Z
Learning: In the OsmoDoc project, the team prefers manual token lifecycle management over automatic TTL expiration in Redis. They deliberately store tokens without expiration to maintain precise control over when tokens become invalid through their dedicated revocation endpoints, rather than relying on automatic expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-07-04T14:44:16.582Z
Learning: In the OsmoDoc project, the team has determined that adding issuer and audience claims to JWT tokens is not required for their specific use case. They have a comprehensive token management system with Redis-based revocation that meets their security requirements without needing additional JWT validation features.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, non-expiry JWT tokens are used intentionally with manual invalidation mechanisms. The team handles token lifecycle management manually rather than using time-based expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:13-16
Timestamp: 2025-07-05T11:50:12.096Z
Learning: In the OsmoDoc project, osm-Jatin prefers to keep performance optimizations simple for infrequently used endpoints like the login endpoint, choosing not to implement caching optimizations when the endpoint usage is expected to be rare.
OsmoDoc.API/OsmoDoc.API.sln (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AutoMappingProfile.cs:9-11
Timestamp: 2025-07-04T03:10:35.535Z
Learning: osm-Jatin indicated that AutoMapper mapping configurations are not needed in the empty AutoMappingProfile constructor in the OsmoDoc project, suggesting they may not be using AutoMapper for certain mappings or have alternative approaches.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
.github/PULL_REQUEST_TEMPLATE/pull_request_template_api.md (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:3-7
Timestamp: 2025-07-04T03:19:33.236Z
Learning: osm-Jatin prefers to defer non-critical code improvements like thread safety enhancements and validation logic when they are not essential for the current PR scope, preferring to keep changes focused on the main objectives.
OsmoDoc/Pdf/Models/ContentMetaData.cs (7)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
OsmoDoc.API/OsmoDoc.API.csproj (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AutoMappingProfile.cs:9-11
Timestamp: 2025-07-04T03:10:35.535Z
Learning: osm-Jatin indicated that AutoMapper mapping configurations are not needed in the empty AutoMappingProfile constructor in the OsmoDoc project, suggesting they may not be using AutoMapper for certain mappings or have alternative approaches.
docs/site/10.0.2/api/OsmoDoc.Word.Models.DocumentData.html (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
OsmoDoc.API/Helpers/Base64StringHelper.cs (3)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
OsmoDoc.API/Helpers/CommonMethodsHelper.cs (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Controllers/WordController.cs:46-47
Timestamp: 2025-06-19T18:01:38.314Z
Learning: In the OsmoDoc project, the `CreateDirectoryIfNotExists` method in `CommonMethodsHelper` is designed to accept file paths as parameters. It internally uses `Path.GetDirectoryName(filePath)` to extract the directory path before creating the directory, so passing full file paths to this method is the correct usage pattern.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
OsmoDoc.API/Helpers/AuthenticationHelper.cs (6)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Program.cs:98-112
Timestamp: 2025-06-20T14:36:43.563Z
Learning: In the OsmoDoc project, JWT tokens are intentionally designed to be non-expiring. The custom LifetimeValidator in Program.cs always returns true to prevent token expiration validation, which is by design rather than a bug.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, non-expiry JWT tokens are used intentionally with manual invalidation mechanisms. The team handles token lifecycle management manually rather than using time-based expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-07-04T14:44:16.582Z
Learning: In the OsmoDoc project, the team has determined that adding issuer and audience claims to JWT tokens is not required for their specific use case. They have a comprehensive token management system with Redis-based revocation that meets their security requirements without needing additional JWT validation features.
docs/site/10.0.2/api/OsmoDoc.Word.Models.ParentBody.html (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
docs/site/10.0.2/api/OsmoDoc.Word.Models.html (6)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
OsmoDoc.sln (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AutoMappingProfile.cs:9-11
Timestamp: 2025-07-04T03:10:35.535Z
Learning: osm-Jatin indicated that AutoMapper mapping configurations are not needed in the empty AutoMappingProfile constructor in the OsmoDoc project, suggesting they may not be using AutoMapper for certain mappings or have alternative approaches.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
OsmoDoc.API/Models/RevokeTokenRequestDTO.cs (10)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/RedisTokenStoreService.cs:18-24
Timestamp: 2025-06-20T14:36:49.953Z
Learning: In the OsmoDoc project, the team prefers manual token lifecycle management over automatic TTL expiration in Redis. They deliberately store tokens without expiration to maintain precise control over when tokens become invalid through their dedicated revocation endpoints, rather than relying on automatic expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc.API/Controllers/LoginController.cs:25-31
Timestamp: 2025-06-21T16:53:18.086Z
Learning: In ASP.NET Core controllers, data annotations like [Required] and [EmailAddress] on DTO properties provide automatic model validation that eliminates the need for explicit null checks in most scenarios, as the framework handles validation before the action method executes.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Program.cs:98-112
Timestamp: 2025-06-20T14:36:43.563Z
Learning: In the OsmoDoc project, JWT tokens are intentionally designed to be non-expiring. The custom LifetimeValidator in Program.cs always returns true to prevent token expiration validation, which is by design rather than a bug.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-07-04T14:44:16.582Z
Learning: In the OsmoDoc project, the team has determined that adding issuer and audience claims to JWT tokens is not required for their specific use case. They have a comprehensive token management system with Redis-based revocation that meets their security requirements without needing additional JWT validation features.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, non-expiry JWT tokens are used intentionally with manual invalidation mechanisms. The team handles token lifecycle management manually rather than using time-based expiration.
OsmoDoc.API/Helpers/AutoMappingProfile.cs (2)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AutoMappingProfile.cs:9-11
Timestamp: 2025-07-04T03:10:35.535Z
Learning: osm-Jatin indicated that AutoMapper mapping configurations are not needed in the empty AutoMappingProfile constructor in the OsmoDoc project, suggesting they may not be using AutoMapper for certain mappings or have alternative approaches.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
docs/site/manifest.json (1)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentType.html (3)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
docs/site/10.0.2/api/OsmoDocWord.html (7)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs (6)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/RedisTokenStoreService.cs:18-24
Timestamp: 2025-06-20T14:36:49.953Z
Learning: In the OsmoDoc project, the team prefers manual token lifecycle management over automatic TTL expiration in Redis. They deliberately store tokens without expiration to maintain precise control over when tokens become invalid through their dedicated revocation endpoints, rather than relying on automatic expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs:5-10
Timestamp: 2025-06-20T15:03:58.820Z
Learning: StackExchange.Redis basic methods (StringSetAsync, KeyExistsAsync, KeyDeleteAsync) don't directly support CancellationToken parameters. The recommended approach is to use cancellationToken.ThrowIfCancellationRequested() for early cancellation detection before Redis operations.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-07-04T14:44:16.582Z
Learning: In the OsmoDoc project, the team has determined that adding issuer and audience claims to JWT tokens is not required for their specific use case. They have a comprehensive token management system with Redis-based revocation that meets their security requirements without needing additional JWT validation features.
OsmoDoc/Word/Models/DocumentData.cs (9)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
.env.example (3)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
OsmoDoc/Word/Models/TableData.cs (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
docs/site/10.0.2/api/OsmoDoc.Word.WordDocumentGenerator.html (9)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
docs/site/10.0.2/api/toc.html (2)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
OsmoDoc.API/Models/PdfGenerationRequestDTO.cs (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
OsmoDoc/Word/Models/Enums.cs (3)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
OsmoDoc/OsmoDoc.csproj (10)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AutoMappingProfile.cs:9-11
Timestamp: 2025-07-04T03:10:35.535Z
Learning: osm-Jatin indicated that AutoMapper mapping configurations are not needed in the empty AutoMappingProfile constructor in the OsmoDoc project, suggesting they may not be using AutoMapper for certain mappings or have alternative approaches.
OsmoDoc/Word/Models/ContentData.cs (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
OsmoDoc.API/Models/BaseResponse.cs (2)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc.API/Controllers/LoginController.cs:25-31
Timestamp: 2025-06-21T16:53:18.086Z
Learning: In ASP.NET Core controllers, data annotations like [Required] and [EmailAddress] on DTO properties provide automatic model validation that eliminates the need for explicit null checks in most scenarios, as the framework handles validation before the action method executes.
OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
docs/site/10.0.2/api/OsmoDoc.Word.Models.TableData.html (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentData.html (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
OsmoDoc.API/Models/WordGenerationRequestDTO.cs (8)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
OsmoDoc/Pdf/Models/DocumentData.cs (8)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
OsmoDoc.API/Program.cs (8)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Program.cs:98-112
Timestamp: 2025-06-20T14:36:43.563Z
Learning: In the OsmoDoc project, JWT tokens are intentionally designed to be non-expiring. The custom LifetimeValidator in Program.cs always returns true to prevent token expiration validation, which is by design rather than a bug.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
OsmoDoc/Pdf/PdfDocumentGenerator.cs (10)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
CONTRIBUTING.md (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.
OsmoDoc.API/Models/LoginRequestDTO.cs (3)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc.API/Controllers/LoginController.cs:25-31
Timestamp: 2025-06-21T16:53:18.086Z
Learning: In ASP.NET Core controllers, data annotations like [Required] and [EmailAddress] on DTO properties provide automatic model validation that eliminates the need for explicit null checks in most scenarios, as the framework handles validation before the action method executes.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
OsmoDoc.API/Controllers/WordController.cs (9)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
README.md (10)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
OsmoDoc/Word/Models/ImageData.cs (9)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc.API/Controllers/LoginController.cs:25-31
Timestamp: 2025-06-21T16:53:18.086Z
Learning: In ASP.NET Core controllers, data annotations like [Required] and [EmailAddress] on DTO properties provide automatic model validation that eliminates the need for explicit null checks in most scenarios, as the framework handles validation before the action method executes.
OsmoDoc/Word/WordDocumentGenerator.cs (11)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Word/WordDocumentGenerator.cs:0-0
Timestamp: 2025-06-20T14:47:35.545Z
Learning: NPOI's XWPFDocument.Write method does not support async operations (WriteAsync is not available), so when working with NPOI Word document generation, synchronous write operations should be used rather than attempting to make them async.
OsmoDoc.API/Controllers/PdfController.cs (7)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Dockerfile (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
OsmoDoc/Services/RedisTokenStoreService.cs (8)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/RedisTokenStoreService.cs:18-24
Timestamp: 2025-06-20T14:36:49.953Z
Learning: In the OsmoDoc project, the team prefers manual token lifecycle management over automatic TTL expiration in Redis. They deliberately store tokens without expiration to maintain precise control over when tokens become invalid through their dedicated revocation endpoints, rather than relying on automatic expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-07-04T14:44:16.582Z
Learning: In the OsmoDoc project, the team has determined that adding issuer and audience claims to JWT tokens is not required for their specific use case. They have a comprehensive token management system with Redis-based revocation that meets their security requirements without needing additional JWT validation features.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs:5-10
Timestamp: 2025-06-20T15:03:58.820Z
Learning: StackExchange.Redis basic methods (StringSetAsync, KeyExistsAsync, KeyDeleteAsync) don't directly support CancellationToken parameters. The recommended approach is to use cancellationToken.ThrowIfCancellationRequested() for early cancellation detection before Redis operations.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Program.cs:98-112
Timestamp: 2025-06-20T14:36:43.563Z
Learning: In the OsmoDoc project, JWT tokens are intentionally designed to be non-expiring. The custom LifetimeValidator in Program.cs always returns true to prevent token expiration validation, which is by design rather than a bug.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, non-expiry JWT tokens are used intentionally with manual invalidation mechanisms. The team handles token lifecycle management manually rather than using time-based expiration.
docs/site/xrefmap.yml (9)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
OsmoDoc.API/Controllers/LoginController.cs (6)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:13-16
Timestamp: 2025-07-05T11:50:12.096Z
Learning: In the OsmoDoc project, osm-Jatin prefers to keep performance optimizations simple for infrequently used endpoints like the login endpoint, choosing not to implement caching optimizations when the endpoint usage is expected to be rare.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/LoginController.cs:42-43
Timestamp: 2025-07-04T03:45:35.740Z
Learning: In the OsmoDoc project, the team follows a specific logging pattern that includes logging both the exception message and stack trace using `_logger.LogError(ex.Message)` and `_logger.LogError(ex.StackTrace)` as seen in LoginController.cs. This is their established pattern for error logging across the application.
🧬 Code Graph Analysis (4)
OsmoDoc.API/Models/PdfGenerationRequestDTO.cs (2)
OsmoDoc/Word/Models/DocumentData.cs (1)
DocumentData(11-28)OsmoDoc/Pdf/Models/DocumentData.cs (1)
DocumentData(7-10)
OsmoDoc.API/Models/WordGenerationRequestDTO.cs (3)
OsmoDoc/Word/Models/ContentData.cs (1)
ContentData(7-29)OsmoDoc/Word/Models/TableData.cs (1)
TableData(9-22)OsmoDoc/Word/Models/ImageData.cs (1)
ImageData(13-39)
OsmoDoc/Pdf/Models/DocumentData.cs (2)
OsmoDoc/Word/Models/DocumentData.cs (1)
DocumentData(11-28)OsmoDoc/Pdf/Models/ContentMetaData.cs (1)
ContentMetaData(3-7)
OsmoDoc/Pdf/PdfDocumentGenerator.cs (2)
OsmoDoc/Pdf/Models/ContentMetaData.cs (1)
ContentMetaData(3-7)OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs (1)
OsmoDocPdfConfig(3-7)
🪛 LanguageTool
README.md
[duplication] ~1-~1: Possible typo: you repeated a word.
Context: # OsmoDoc OsmoDoc is a library with the following functio...
(ENGLISH_WORD_REPEAT_RULE)
[uncategorized] ~30-~30: You might be missing the article “a” here.
Context: ...te](.env.example) into .env. Then set suitable JWT key. 7. Set environment variables...
(AI_EN_LECTOR_MISSING_DETERMINER_A)
🪛 markdownlint-cli2 (0.17.2)
README.md
33-33: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4
(MD001, heading-increment)
112-112: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4
(MD001, heading-increment)
🪛 YAMLlint (1.37.1)
docker-compose.yaml
[error] 32-32: no new line character at the end of file
(new-line-at-end-of-file)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Analyze (csharp)
🔇 Additional comments (38)
OsmoDoc.API/OsmoDoc.API.sln (1)
6-6: Confirm.csprojpath remains correct after rename
"OsmoDoc.API.csproj"is now referenced from the solution root.
Double-check that the physical file really moved/was renamed accordingly; otherwisedotnet buildwill break..gitignore (1)
355-357: 👍 Top-levelTemp/ignore looks goodAdds coverage for the Docker-mounted folder without interfering with existing
**/wwwroot/Temprule.
No issues spotted..github/PULL_REQUEST_TEMPLATE/pull_request_template_api.md (1)
5-5: Updated repo link LGTM
The link now correctly targetsosmodoc.
Good catch.OsmoDoc.API/OsmoDoc.API.csproj (2)
11-11: Confirm Redis runtime dependency is documentedAdding
StackExchange.Redisis fine, but the API will now fail fast if a Redis endpoint isn’t available in non-Docker/dev environments.
Please ensure the README / deployment docs updated by this PR mention:
- required environment variables for Redis host/port/password
- a docker-compose override (if applicable)
Otherwise newcomers will hit runtime connection exceptions.
16-16: Project reference path : double-check relative locationThe
ProjectReferencejumps up one level (..) then intoOsmoDoc\OsmoDoc.csproj.
If the API project is already at solution root, the extra..will break CI builds on Windows/Linux with different casing.
Please verify the resulting path resolves in your build pipeline.docs/site/10.0.2/api/OsmoDocWord.html (1)
8-12: Namespace rename looks correct
Only textual updates; no functional concerns.docs/site/manifest.json (1)
3-4: Manifest paths updated – LGTMRelative
source_base_pathand namespace rewrites line up with the new folder structure.Also applies to: 8-82
docs/site/10.0.2/api/OsmoDoc.Word.Models.ParentBody.html (1)
70-82: Namespace/assembly rename looks correct.The
data-uid, header id, namespace, and assembly have been updated consistently toOsmoDoc.Word.Models. No further action required.docs/site/10.0.2/api/OsmoDoc.Word.Models.html (1)
70-93: Documentation points to renamed types correctly.Links and
data-uids now referenceOsmoDoc.Word.Models.*and render as expected.
No issues spotted.docs/site/10.0.2/api/OsmoDoc.Word.Models.DocumentData.html (1)
70-110: Documentation accurately reflects namespace migration
Alldata-uid, heading IDs, and namespace/assembly references now point toOsmoDoc.Word.Models.*. No broken xrefs spotted.docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentData.html (1)
70-110: ContentData docs updated correctly
Renaming changes look consistent; cross-links (ContentType,ParentBody) resolve to new locations.OsmoDoc.API/Helpers/AutoMappingProfile.cs (1)
7-12: Empty profile – verify if AutoMapper is still required
The profile contains no mappings. If AutoMapper is no longer used, consider removing the package & startup registration to trim dependencies; otherwise add the intended mappings.OsmoDoc.sln (1)
6-9: Solution rename looks correct
Projects now referenceOsmoDocandOsmoDoc.API; GUIDs unchanged and build configurations preserved.OsmoDoc.API/Helpers/CommonMethodsHelper.cs (3)
3-3: LGTM: Namespace updated correctly.The namespace change from
DocumentService.API.HelperstoOsmoDoc.API.Helpersaligns with the project-wide refactoring.
9-12: Good defensive programming practice.The input validation for
filePathparameter prevents potential exceptions fromPath.GetDirectoryName()when passed null or empty values.
16-16: Correct nullable type usage.The nullable
string?type is appropriate sincePath.GetDirectoryName()can return null for certain inputs (e.g., root paths).OsmoDoc.API/Models/RevokeTokenRequestDTO.cs (1)
5-9: LGTM: Well-structured DTO with proper validation.The DTO follows established patterns with:
- Required validation attribute for automatic model validation
- Proper initialization to prevent null values
- Clear property naming and purpose
This integrates well with the Redis-based token management system.
OsmoDoc/Word/Models/TableData.cs (1)
9-22: LGTM: Well-designed model class with excellent documentation.The
TableDataclass follows established patterns:
- Collection property initialized to prevent null values (
= new())- Comprehensive XML documentation explaining the purpose and structure
- Clear property naming and types
This aligns with the defensive programming approach used throughout the OsmoDoc project.
.env.example (1)
1-10: LGTM: Comprehensive environment configuration for Redis integration.The updates provide:
- Clear guidance for JWT_KEY security requirements (min 32 characters)
- Complete Redis configuration variables for the new token management system
- Proper default values that align with the Docker Compose setup
- Clear naming conventions for all variables
This supports the new Redis-based token management functionality effectively.
docs/site/10.0.2/api/toc.html (1)
17-43: LGTM: Documentation consistently updated for namespace refactoring.All navigation links have been properly updated from
DocumentService.WordtoOsmoDoc.Word, maintaining:
- Consistent naming throughout the table of contents
- Proper link structure and hierarchy
- Complete coverage of all model classes and generators
This ensures the documentation remains synchronized with the codebase changes.
OsmoDoc.API/Models/LoginRequestDTO.cs (1)
5-10: LGTM! Clean and well-structured DTO implementation.The implementation follows ASP.NET Core best practices with proper data annotations for validation. The
[Required]and[EmailAddress]attributes will provide automatic model validation, and initializing the Email property tostring.Emptyis a good defensive programming practice.OsmoDoc/OsmoDoc.csproj (1)
1-27: LGTM! Well-configured project file with comprehensive NuGet metadata.The project file is properly configured for .NET 8.0 with appropriate package references for document generation functionality. The NuGet package metadata is comprehensive and follows best practices for package publishing.
OsmoDoc.API/Models/PdfGenerationRequestDTO.cs (1)
6-12: LGTM! Consistent with project patterns and well-designed for PDF generation.The implementation follows the established patterns in the OsmoDoc project:
- Proper use of
requiredkeyword for critical properties- DocumentData initialization with
= new()to prevent null reference issues- Appropriate nullable annotation for optional SerializedEjsDataJson
The design effectively supports the PDF generation workflow with proper validation.
docs/site/10.0.2/api/OsmoDoc.Word.Models.TableData.html (1)
70-70: LGTM! Documentation updates are consistent with the namespace migration.All namespace and assembly references have been properly updated from
DocumentService.Word.ModelstoOsmoDoc.Word.Modelsand fromDocumentService.dlltoOsmoDoc.dll. The updates are comprehensive and maintain consistency throughout the documentation.Also applies to: 74-74, 107-108, 109-109, 115-116, 139-140
docs/site/10.0.2/api/OsmoDoc.Word.WordDocumentGenerator.html (1)
70-70: LGTM! Documentation updates are thorough and consistent with the namespace migration.All namespace and assembly references have been properly updated from
DocumentService.WordtoOsmoDoc.Wordand fromDocumentService.dlltoOsmoDoc.dll. The DocumentData type reference has been correctly updated to point toOsmoDoc.Word.Models.DocumentData. The updates maintain documentation consistency and accuracy.Also applies to: 74-74, 107-108, 115-116, 139-139
OsmoDoc/Word/Models/Enums.cs (2)
7-13: LGTM: Well-defined enum with clear documentation.The ContentType enum is properly defined with comprehensive XML documentation.
18-30: LGTM: ParentBody enum is well-structured.The enum properly defines the parent body contexts for Word document placeholders.
OsmoDoc/Word/Models/DocumentData.cs (1)
11-28: LGTM: Well-structured class following established patterns.The DocumentData class properly initializes all collections with empty lists, which aligns with the established pattern in the OsmoDoc project and prevents null reference exceptions.
OsmoDoc.API/Models/BaseResponse.cs (1)
24-37: LGTM: Improved error handling with robust null checks.The refactored
ModelValidationErrorResponsemethod properly handles null ModelState values and extracts the first meaningful error message with appropriate fallback. The implementation is more robust and follows good practices.OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs (1)
6-11: LGTM: Well-designed interface with proper async patterns.The interface properly defines the token management operations with appropriate async signatures and CancellationToken support. The method signatures align with the Redis-based token management approach used in the OsmoDoc project.
docs/site/xrefmap.yml (1)
4-195: Documentation namespace updates are consistent.All references have been properly updated from
DocumentService.WordtoOsmoDoc.Wordthroughout the documentation cross-reference file, aligning with the project-wide namespace migration.OsmoDoc/Word/Models/ImageData.cs (1)
6-39: Well-implemented image data model with appropriate validation.The
ImageDataclass properly validates thatImageExtensionis required whenSourceTypeis Base64, which is essential for proper image handling. The enum design and property initialization follow best practices.OsmoDoc.API/Controllers/WordController.cs (1)
148-172: Excellent cleanup implementation.The finally block ensures proper cleanup of temporary files with appropriate error logging, aligning with the project's cleanup scope requirements as noted in previous learnings.
OsmoDoc/Services/RedisTokenStoreService.cs (1)
19-29: Implementation aligns well with the team's token management approach.The non-expiring token storage and manual revocation pattern correctly implements the team's preferred JWT + Redis hybrid approach as established in previous PRs. The cancellation token usage follows the recommended pattern for StackExchange.Redis.
Dockerfile (2)
5-7: LGTM! Production build configuration is appropriate.The change to Release/Production configuration is correct for the production Docker image.
36-40: Good consolidation of package installation.Combining the package installation into a single RUN command reduces the number of Docker layers and properly cleans up the apt cache.
OsmoDoc/Pdf/PdfDocumentGenerator.cs (1)
87-87: Verify the quadruple brace placeholder pattern.The placeholder replacement uses
{{{{placeholder}}}}pattern. This seems unusual as typically placeholders use double braces{{placeholder}}. Please verify if this is intentional for escaping purposes or if it should be simplified.OsmoDoc.API/Program.cs (1)
165-169: Verify if Swagger UI in production is intentional.Swagger UI is now enabled in both Development and Production environments. While this can be useful for API documentation, it may expose sensitive API structure in production. Please confirm this is intentional.
| <tr> | ||
| <td id="DocumentService_Word_Models_ContentType_Image">Image</td> | ||
| <td id="OsmoDoc_Word_Models_ContentType_Image">Image</td> | ||
| <td>The placeholder represents an image.</td> | ||
| </tr> | ||
| <tr> | ||
| <td id="DocumentService_Word_Models_ContentType_Text">Text</td> | ||
| <td id="OsmoDoc_Word_Models_ContentType_Text">Text</td> | ||
| <td>The placeholder represents text content.</td> | ||
| </tr> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docs out of sync with code – enum still lists Image.
The current source code (per PR summary) states ContentType only contains Text, yet the generated docs list both Image and Text. Regenerate the docs after updating the enum or adjust the enum if removal was accidental.
🤖 Prompt for AI Agents
In docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentType.html around lines 95 to
102, the documentation lists both "Image" and "Text" as enum values, but the
source code enum only includes "Text". To fix this, verify the enum definition
in the source code and either remove "Image" from the enum if it was removed
intentionally or add it back if its removal was accidental. Then regenerate the
documentation to ensure it matches the updated enum values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these docs manually created or with some buil-in library. I have no clue about this docs/ folder. Can you explain
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
@osm-Jatin I'll investigate the documentation setup in your project to explain how these docs are generated.
🏁 Script executed:
#!/bin/bash
# Look for DocFX configuration files
find . -name "docfx.json" -o -name "*.docfx.json" 2>/dev/null
# Search for documentation-related build scripts or workflows
find . -name "*.yml" -o -name "*.yaml" | xargs grep -l -i "docfx\|documentation\|docs" 2>/dev/null || true
# Look for any documentation setup in README files
find . -name "README*" -exec grep -l -i "docfx\|documentation\|docs" {} \; 2>/dev/null || true
# Check if there are any package.json or project files mentioning documentation tools
find . -name "package.json" -o -name "*.csproj" | xargs grep -l -i "docfx\|documentation" 2>/dev/null || true
# Look at the docs directory structure
ls -la docs/ 2>/dev/null || echo "No docs directory found"
# Check for any build scripts
find . -name "build.sh" -o -name "build.ps1" -o -name "*.bat" | head -5
Length of output: 612
🏁 Script executed:
#!/bin/bash
# Examine the DocFX configuration file
echo "=== DocFX Configuration ==="
cat ./docfx.json
echo -e "\n=== Docs directory structure ==="
find docs/ -type f | head -10
echo -e "\n=== Check for GitHub Actions or CI that might build docs ==="
find .github/ -name "*.yml" -o -name "*.yaml" | xargs grep -l -i "docfx" 2>/dev/null || echo "No CI/CD files found with DocFX"
echo -e "\n=== Check manifest.json for more details ==="
head -20 docs/site/manifest.json 2>/dev/null || echo "No manifest found"
Length of output: 2490
@osm-Jatin Based on my investigation, here's what I found about your documentation setup:
DocFX Auto-Generated Documentation
Your docs are auto-generated using DocFX, a Microsoft documentation generation tool for .NET projects. Here's how it works:
Setup:
- Configuration file:
docfx.jsonin your root directory - Tool: DocFX scans your
*.csprojfiles and extracts API documentation from:- XML documentation comments in your code
- Class/method/property signatures
- Assembly metadata
Generation Process:
- DocFX reads your C# code and generates YAML metadata files in
obj/10.0.2/api/ - Converts YAML to HTML files in
docs/site/10.0.2/api/ - Creates cross-reference maps and navigation
Current Issue:
The docs are out of sync with your source code. The HTML shows both Text and Image enum values, but your actual ContentType enum (per the AI summary) only contains Text.
To Fix This:
You need to regenerate the documentation by running:
# Install DocFX (if not already installed)
dotnet tool install -g docfx
# Regenerate docs from current source code
docfx docfx.json --serveManual vs Automated:
- Currently: Manual regeneration (no CI/CD found)
- Recommendation: Add a GitHub Action to auto-regenerate docs on code changes
The docs folder isn't manually created - it's the output of DocFX processing your actual C# code. You just need to regenerate them to match your current source code.
🧠 Learnings used
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T09:27:22.341Z
Learning: osm-Jatin prefers to move entirely to OpenXML SDK for the OsmoDoc NuGet library to eliminate document corruption issues caused by the hybrid NPOI + OpenXML approach, choosing long-term reliability and MS Office compatibility over the simpler NPOI APIs.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:3-7
Timestamp: 2025-07-04T03:19:33.236Z
Learning: osm-Jatin prefers to defer non-critical code improvements like thread safety enhancements and validation logic when they are not essential for the current PR scope, preferring to keep changes focused on the main objectives.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:96-97
Timestamp: 2025-07-04T03:27:39.798Z
Learning: osm-Jatin prefers to defer security-related logging improvements (like removing stack trace logging) when they are not essential for the current PR scope in the OsmoDoc project, choosing to keep existing implementation for now.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:13-16
Timestamp: 2025-07-05T11:50:12.096Z
Learning: In the OsmoDoc project, osm-Jatin prefers to keep performance optimizations simple for infrequently used endpoints like the login endpoint, choosing not to implement caching optimizations when the endpoint usage is expected to be rare.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I run these commands:
- dotnet tool install -g docfx
- docfx docfx.json --serve
Will it override the docs/ directly without my intervention ? Or what steps should I follow to update this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
@osm-Jatin Let me check your DocFX configuration to give you the exact behavior:
🏁 Script executed:
#!/bin/bash
# Examine the DocFX configuration to understand the output settings
echo "=== DocFX Configuration - Build Section ==="
cat docfx.json | jq '.build'
echo -e "\n=== Current docs directory structure ==="
find docs/ -type f | head -5
echo -e "\n=== Check if there are any .gitignore entries for docs ==="
grep -n "docs" .gitignore 2>/dev/null || echo "No docs entries in .gitignore"
echo -e "\n=== Check source and destination paths ==="
cat docfx.json | jq '.build.dest'
Length of output: 1308
Based on your DocFX configuration, here's exactly what will happen and the safe steps to follow:
What the Commands Do:
docfx docfx.json --serve:
- ✅ Safe: Creates a new
_site/directory (won't touch your existingdocs/) - Generates fresh documentation in
_site/10.0.2/api/ - Starts a local web server to preview the docs
- No automatic overwriting of your committed
docs/folder
Step-by-Step Process:
1. Generate Fresh Docs (Safe)
# Install DocFX globally
dotnet tool install -g docfx
# Generate docs and preview locally
docfx docfx.json --serve2. Review the Generated Docs
- DocFX will serve the docs at
http://localhost:8080 - Compare with your current docs to ensure everything looks correct
- Verify the
ContentTypeenum now shows only the correct values
3. Update Your Committed Docs (Manual Step)
# Backup current docs (optional safety measure)
cp -r docs/site docs/site.backup
# Replace with freshly generated docs
rm -rf docs/site/10.0.2
cp -r _site/10.0.2 docs/site/
# Clean up the temporary _site directory
rm -rf _site4. Commit the Changes
git add docs/
git commit -m "docs: regenerate API documentation to sync with current source code"Key Points:
- ✅ Your original
docs/won't be touched automatically - ✅ You control when/if to replace the committed docs
- ✅ You can preview everything before committing
⚠️ The manual copy step is required to update your committed documentation
This gives you full control over the update process!
🧠 Learnings used
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T09:27:22.341Z
Learning: osm-Jatin prefers to move entirely to OpenXML SDK for the OsmoDoc NuGet library to eliminate document corruption issues caused by the hybrid NPOI + OpenXML approach, choosing long-term reliability and MS Office compatibility over the simpler NPOI APIs.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:3-7
Timestamp: 2025-07-04T03:19:33.236Z
Learning: osm-Jatin prefers to defer non-critical code improvements like thread safety enhancements and validation logic when they are not essential for the current PR scope, preferring to keep changes focused on the main objectives.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:96-97
Timestamp: 2025-07-04T03:27:39.798Z
Learning: osm-Jatin prefers to defer security-related logging improvements (like removing stack trace logging) when they are not essential for the current PR scope in the OsmoDoc project, choosing to keep existing implementation for now.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:13-16
Timestamp: 2025-07-05T11:50:12.096Z
Learning: In the OsmoDoc project, osm-Jatin prefers to keep performance optimizations simple for infrequently used endpoints like the login endpoint, choosing not to implement caching optimizations when the endpoint usage is expected to be rare.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
atingupta@fedora:~/Desktop/Work/osmodoc$ docfx docfx.json --serve
No files are found with glob pattern .csproj, excluding /bin/,/obj/, under directory "/home/jatingupta/Desktop/Work/osmodoc"
warning: No .NET API project detected.
Creating output...
warning: No .NET API detected for .
Searching built-in plugins in directory /home/jatingupta/.dotnet/tools/.store/docfx/2.78.3/docfx/2.78.3/tools/net8.0/any/...
No files are found with glob pattern **/.yml,api/*.md, excluding , under directory "/home/jatingupta/Desktop/Work/osmodoc/obj/10.0.2"
7 plug-in(s) loaded.
Applying templates to 0 model(s)...
XRef map exported.
EmptyInputContents: No content file found. Please make sure the content section of docfx.json is correctly configured.
Serving "/home/jatingupta/Desktop/Work/osmodoc/_site" on http://localhost:8080
Press Ctrl+C to shut down
^C
Build succeeded with warning.
2 warning(s)
0 error(s)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
@osm-Jatin The issue is that your docfx.json is missing the metadata section that tells DocFX where to find your .NET projects. Let me check the current configuration and provide the fix:
🏁 Script executed:
#!/bin/bash
# Check current DocFX configuration
echo "=== Current DocFX Configuration ==="
cat docfx.json
echo -e "\n=== Project files locations ==="
find . -name "*.csproj" -type f
echo -e "\n=== Current directory structure ==="
ls -la
Length of output: 2357
Perfect! I found the issue. Your docfx.json has the metadata section, but it's looking for *.csproj files in the current directory when your projects are actually in subdirectories.
The Problem:
- Current pattern:
"*.csproj"in"cwd": "." - Actual projects:
./OsmoDoc.API/OsmoDoc.API.csprojand./OsmoDoc/OsmoDoc.csproj - Wrong target framework:
"net452"(should be"net8.0")
Fix Your docfx.json:
Replace your current docfx.json with this corrected version:
{
"metadata": [{
"src": [{
"files": [
"**/*.csproj"
],
"exclude": ["**/bin/**", "**/obj/**"],
"cwd": "."
}],
"properties": {
"TargetFramework": "net8.0"
},
"dest": "obj/10.0.2/api",
"shouldSkipMarkup": true
}],
"build": {
"content": [
{ "files": ["**/*.yml", "api/*.md"], "src": "obj/10.0.2", "dest": "10.0.2" }
],
"globalMetadata": {
"_appTitle": "OsmoDoc API Documentation",
"_disableContribution": true,
"_appFooter": " ",
"_navRel": "../toc.html"
},
"template": [
"default",
"template"
],
"overwrite": [
{ "files": ["*.md"] }
],
"dest": "_site"
}
}Key Changes:
- ✅
"*.csproj"→"**/*.csproj"(finds projects in subdirectories) - ✅
"net452"→"net8.0"(correct target framework) - ✅ Updated app title to "OsmoDoc API Documentation"
Now Try Again:
# Clean any previous artifacts
rm -rf obj/ _site/
# Generate fresh docs
docfx docfx.json --serveThis should now detect your projects and generate the correct API documentation!
🧠 Learnings used
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:194-198
Timestamp: 2025-07-07T14:45:51.713Z
Learning: osm-Jatin successfully implemented the npx cross-platform compatibility changes for EJS execution in OsmoDoc/Pdf/PdfDocumentGenerator.cs as discussed, using the correct conditional command line assignment and updating the arguments method to use npx consistently across Windows and Linux platforms.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:194-198
Timestamp: 2025-07-07T14:45:51.714Z
Learning: osm-Jatin successfully implemented the npx cross-platform compatibility changes for EJS execution in OsmoDoc/Pdf/PdfDocumentGenerator.cs in PR #54, using the exact implementation discussed: ternary operator for command line assignment (line 196), "/C npx ejs" for Windows (line 243), and "ejs" as first argument for Linux npx execution (line 247).
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#54
File: OsmoDoc.API/Controllers/LoginController.cs:26-31
Timestamp: 2025-07-07T15:09:24.073Z
Learning: In the OsmoDoc project, osm-Jatin prefers to rely on ASP.NET Core's built-in model validation system (using [Required] attributes and ModelValidationBadRequest.ModelValidationErrorResponse in BaseResponse.cs) rather than adding explicit null checks for request parameters in controller methods, as the framework automatically handles validation before action execution.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T09:27:22.341Z
Learning: osm-Jatin prefers to move entirely to OpenXML SDK for the OsmoDoc NuGet library to eliminate document corruption issues caused by the hybrid NPOI + OpenXML approach, choosing long-term reliability and MS Office compatibility over the simpler NPOI APIs.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:3-7
Timestamp: 2025-07-04T03:19:33.236Z
Learning: osm-Jatin prefers to defer non-critical code improvements like thread safety enhancements and validation logic when they are not essential for the current PR scope, preferring to keep changes focused on the main objectives.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:96-97
Timestamp: 2025-07-04T03:27:39.798Z
Learning: osm-Jatin prefers to defer security-related logging improvements (like removing stack trace logging) when they are not essential for the current PR scope in the OsmoDoc project, choosing to keep existing implementation for now.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:13-16
Timestamp: 2025-07-05T11:50:12.096Z
Learning: In the OsmoDoc project, osm-Jatin prefers to keep performance optimizations simple for infrequently used endpoints like the login endpoint, choosing not to implement caching optimizations when the endpoint usage is expected to be rare.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#54
File: OsmoDoc.API/DotEnv.cs:24-47
Timestamp: 2025-07-07T19:05:56.955Z
Learning: osm-Jatin prefers to keep error handling simple in utility methods like DotEnv.Load when the input (e.g., .env files) is expected to be well-formed and reliable, choosing not to over-engineer with extensive validation and error handling.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#54
File: OsmoDoc.API/Helpers/Base64StringHelper.cs:7-8
Timestamp: 2025-07-07T19:21:25.387Z
Learning: osm-Jatin prefers to handle exceptions like FormatException at the controller level using comprehensive catch blocks rather than adding specific exception handling in helper methods like Base64StringHelper.cs, maintaining consistency with the established error handling patterns in the OsmoDoc project.
Task Link
REST-1582
Description
Summary by CodeRabbit
New Features
Refactor
Bug Fixes
Documentation
Chores