refactor: optimize and fix the application code #54
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… all related namespaces
…ding unique id in the filename
…ve generated token to redis
WalkthroughThis update migrates the project from "DocumentService" to "OsmoDoc," renaming all code, configuration, documentation, and Docker assets accordingly. It introduces new Redis-based JWT token management, refactors API controllers for improved validation and resource cleanup, and restructures DTOs and document generation logic. The update also enhances documentation, Docker orchestration, and environment configuration. Changes
Sequence Diagram(s)Login and Token Management FlowsequenceDiagram
participant Client
participant LoginController
participant RedisTokenStoreService
participant JWT_Helper
Client->>LoginController: POST /api/login (email)
LoginController->>JWT_Helper: Generate JWT (email)
JWT_Helper-->>LoginController: JWT token
LoginController->>RedisTokenStoreService: StoreTokenAsync(token, email)
RedisTokenStoreService-->>LoginController: (ack)
LoginController-->>Client: Success response with token
Client->>LoginController: POST /api/revoke (token)
LoginController->>RedisTokenStoreService: RevokeTokenAsync(token)
RedisTokenStoreService-->>LoginController: (ack)
LoginController-->>Client: Success response
PDF Generation (HTML/EJS) FlowsequenceDiagram
participant Client
participant PdfController
participant PdfDocumentGenerator
participant FileSystem
Client->>PdfController: POST /api/pdf (PdfGenerationRequestDTO)
PdfController->>FileSystem: Save base64 template to temp file
PdfController->>PdfDocumentGenerator: GeneratePdf(templatePath, metaData, outputPath, isEjs, ejsJson)
PdfDocumentGenerator->>FileSystem: (Handles temp files, runs wkhtmltopdf)
PdfDocumentGenerator-->>PdfController: (await completion)
PdfController->>FileSystem: Cleanup temp files
PdfController-->>Client: PDF file response / download link
Word Document Generation FlowsequenceDiagram
participant Client
participant WordController
participant WordDocumentGenerator
participant FileSystem
Client->>WordController: POST /api/word (WordGenerationRequestDTO)
WordController->>FileSystem: Save base64 template to temp file
WordController->>WordDocumentGenerator: GenerateDocumentByTemplate(templatePath, documentData, outputPath)
WordDocumentGenerator->>FileSystem: (Handles temp files, replaces placeholders, images, tables)
WordDocumentGenerator-->>WordController: (await completion)
WordController->>FileSystem: Cleanup temp files
WordController-->>Client: Word file response / download link
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ 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)
✨ 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🔭 Outside diff range comments (1)
docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentType.html (1)
70-102: Remove staleImageentry from ContentType docsThe
ContentTypeenum in OsmoDoc/Word/Models/Enums.cs only defines a single member (Text), but the generated API page still lists bothImageandText. Please regenerate or update the documentation so that onlyTextappears:• File: docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentType.html
– In the<tbody>under Fields, remove the entire<tr>forImage:- <tr> - <td id="OsmoDoc_Word_Models_ContentType_Image">Image</td> - <td>The placeholder represents an image.</td> - </tr>• After updating, rerun your doc‐generation tool to ensure the reference matches the actual enum members.
🧹 Nitpick comments (20)
.github/PULL_REQUEST_TEMPLATE/pull_request_template_api.md (1)
5-5: Link fixed—consider switching to a relative path for repo-moves resilienceThe absolute GitHub URL is correct after the rename, but a relative link
(e.g.../CONTRIBUTING.md#submitting-a-pull-request-pr) would survive future org/branch moves and makes forks’ links work out-of-the-box.
No functional blocker; up to you.OsmoDoc.API/Helpers/AutoMappingProfile.cs (2)
2-3: Remove unusedusingdirectives
OsmoDoc.Word.ModelsandOsmoDoc.API.Modelsare not referenced in this file. Leaving them in will trigger CS8019 warnings in most build configurations that treat warnings as errors.-using OsmoDoc.Word.Models; -using OsmoDoc.API.Models;
9-11: Empty profile: verify whether AutoMapper is still requiredThe constructor is intentionally empty, consistent with the team’s prior decision to avoid AutoMapper mappings for now.
If AutoMapper is no longer used anywhere (or only viaIMapperextension methods that don’t need explicit profiles), consider:
- Removing this profile altogether to avoid the startup cost of scanning an empty profile.
- Marking the class as
sealedto make its purpose explicit and prevent accidental inheritance.Otherwise, add a brief comment explaining why the profile is intentionally left blank to prevent future confusion.
OsmoDoc.API/Helpers/Base64StringHelper.cs (2)
16-17: Create parent directory before writingIf
filePathpoints to a folder that doesn’t yet exist,WriteAllBytesAsyncthrowsDirectoryNotFoundException.
CallDirectory.CreateDirectory(Path.GetDirectoryName(filePath)!)first.
23-24: Consider streaming to reduce memory pressure
ReadAllBytesAsyncloads the entire file into RAM.
For large files you already accepted inSaveBase64StringToFilePath, this doubles peak memory usage.
A buffered stream →Convert.ToBase64Stringoverload can avoid that.Not critical for small limits, but worth tracking.
OsmoDoc/Pdf/Models/ContentMetaData.cs (1)
5-6: Consider adding XML-docs for public DTOsInline XML comments (
<summary>/<param>…) make IntelliSense friendlier for package consumers.- public string Placeholder { get; set; } = string.Empty; - public string Content { get; set; } = string.Empty; + /// <summary>Marker that appears in the template, e.g. <c>{InvoiceNo}</c>.</summary> + public string Placeholder { get; set; } = string.Empty; + + /// <summary>Replacement text that will be injected in place of the marker.</summary> + public string Content { get; set; } = string.Empty;OsmoDoc/Pdf/Models/DocumentData.cs (1)
9-10: Align collection initialiser style with Word modelsElsewhere in the project (
OsmoDoc.Word.Models.DocumentData) you use the terse= new();syntax.
For consistency:- public List<ContentMetaData> Placeholders { get; set; } = new List<ContentMetaData>(); + public List<ContentMetaData> Placeholders { get; set; } = new();OsmoDoc.API/Helpers/AuthenticationHelper.cs (1)
10-26: Parameter naming & key-length nit
- C# convention is camelCase for parameters –
loginEmailinstead ofLoginEmail.- HMAC-SHA256 benefits from a ≥ 32-byte key. Consider validating length to fail fast if
JWT_KEYis too short.- public static string JwtTokenGenerator(string LoginEmail) + public static string JwtTokenGenerator(string loginEmail) ... - new(ClaimTypes.Email, LoginEmail), + new(ClaimTypes.Email, loginEmail), + + // Optional – enforce minimum key length + if (secretKey.Key.Length < 32) + throw new InvalidOperationException("JWT_KEY must be at least 256-bit (32 bytes)");OsmoDoc/Word/Models/DocumentData.cs (1)
1-4: Remove unused using statements.The
SystemandSystem.Textusing statements appear to be unused in this file. OnlySystem.Collections.Genericis actually needed for theList<T>types.-using System; using System.Collections.Generic; -using System.Text;OsmoDoc/Word/Models/ContentData.cs (1)
1-29: Consider removing extra blank lines for consistency.The model is well-structured with proper XML documentation and defensive string initialization. However, there are extra blank lines at line 3 and within the ParentBody property documentation (line 27).
namespace OsmoDoc.Word.Models; - /// <summary> /// Represents the data for a content placeholder in a Word document. /// </summary>/// <summary> /// Gets or sets the parent body of the placeholder (none or table). /// </summary> - public ParentBody ParentBody { get; set; }OsmoDoc.API/Program.cs (1)
129-133: Extract "Bearer " prefix as a constant.The hardcoded string length makes the code less maintainable. Consider extracting the bearer prefix as a constant.
+private const string BearerPrefix = "Bearer "; + // ... in OnTokenValidated event handler if (context.Request.Headers.TryGetValue("Authorization", out Microsoft.Extensions.Primitives.StringValues authHeader) && - authHeader.ToString().StartsWith("Bearer ", StringComparison.OrdinalIgnoreCase)) + authHeader.ToString().StartsWith(BearerPrefix, StringComparison.OrdinalIgnoreCase)) { - tokenString = authHeader.ToString().Substring("Bearer ".Length).Trim(); + tokenString = authHeader.ToString().Substring(BearerPrefix.Length).Trim(); }OsmoDoc.API/Models/WordGenerationRequestDTO.cs (1)
17-19: Simplify list initialization for consistency.Since C# supports target-typed new expressions, you can simplify the list initializations to match modern C# conventions.
- 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();README.md (2)
30-30: Add missing article for grammatical correctness.-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 level progression.Markdown heading levels should increment by one level at a time. Change from h4 (####) to h3 (###) for proper document structure.
-#### Development +### Development-#### HTML TO PDF +### HTML TO PDF-#### EJS TO PDF +### EJS TO PDFAlso applies to: 112-112
OsmoDoc.API/Controllers/WordController.cs (2)
87-87: Remove redundant boolean comparison.The
== truecomparison is unnecessary for boolean expressions.- if (request.DocumentData.ImagesData.Any(img => string.IsNullOrEmpty(img.Data)) == true) + if (request.DocumentData.ImagesData.Any(img => string.IsNullOrEmpty(img.Data)))
154-154: Use File class directly for consistency.You can use
Filedirectly instead of the fully qualifiedSystem.IO.Filesince there's no naming conflict.- System.IO.File.Delete(docxTemplateFilePath); + File.Delete(docxTemplateFilePath);- System.IO.File.Delete(outputFilePath); + File.Delete(outputFilePath);Also applies to: 165-165
docker-compose.yaml (1)
32-32: Add newline at end of fileYAML files should end with a newline character for better compatibility with various tools.
networks: osmodoc-net: driver: bridge +OsmoDoc/Pdf/PdfDocumentGenerator.cs (1)
255-284: Consider adding configurable logging instead of Console.WriteLineThe cleanup method correctly handles exceptions without throwing, but uses
Console.WriteLinefor warnings. Consider adding a logging configuration pattern similar toWordDocumentGenerator.ConfigureLoggingfor consistency.Add a static logger field and configuration method at the class level:
public static class PdfDocumentGenerator { + private static ILogger _logger = NullLogger.Instance; + + /// <summary> + /// Configures logging for the PdfDocumentGenerator + /// </summary> + /// <param name="logger">Logger instance to use</param> + public static void ConfigureLogging(ILogger logger) + { + _logger = logger ?? NullLogger.Instance; + } +Then update the cleanup method:
- Console.WriteLine($"Warning: Could not delete EJS converted HTML file {ejsConvertedHtmlPath}: {ex.Message}"); + _logger.LogWarning(ex, $"Could not delete EJS converted HTML file {ejsConvertedHtmlPath}");- Console.WriteLine($"Warning: Could not delete temporary directory {tempModifiedHtmlDirectory}: {ex.Message}"); + _logger.LogWarning(ex, $"Could not delete temporary directory {tempModifiedHtmlDirectory}");docs/site/10.0.2/api/OsmoDocWord.html (2)
8-12: Strip unintended newline from<title>/metaattributesThere’s an embedded line-break after
OsmoDoc.Wordinside both the<title>element and themeta name="title"attribute. Some browsers render that newline as a literal space, but others may collapse it or treat it inconsistently, and it also pollutes the search-index string produced by DocFX.-<title>Namespace OsmoDoc.Word - | Some Documentation </title> +<title>Namespace OsmoDoc.Word | Some Documentation</title> -<meta name="title" content="Namespace OsmoDoc.Word - | Some Documentation "> +<meta name="title" content="Namespace OsmoDoc.Word | Some Documentation">
70-81: Add DocFX redirect for the oldDocumentService.WordnamespaceAll internal links in the generated site are now updated, but any bookmarked URLs or external references to
api/DocumentServiceWord.html(and the old WordDocumentGenerator page) will 404 after this rename.DocFX supports redirection via
redirects:in docfx.json or aredirections.yml. Adding:- uid: DocumentService.Word redirect_url: api/OsmoDocWord.html - uid: DocumentService.Word.WordDocumentGenerator redirect_url: api/OsmoDoc.Word.WordDocumentGenerator.htmlpreserves existing links and improves SEO.
📜 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/Word/Models/ContentData.cs
- DocumentService/Pdf/Models/ContentMetaData.cs
- DocumentService/Word/Models/TableData.cs
- DocumentService.API/Models/PdfGenerationRequestDTO.cs
- DocumentService/Word/Models/DocumentData.cs
- DocumentService.API/Helpers/AutoMappingProfile.cs
- DocumentService/DocumentService.csproj
- DocumentService/Pdf/Models/DocumentData.cs
- DocumentService.API/Models/WordGenerationRequestDTO.cs
- DocumentService/Word/Models/Enums.cs
- DocumentService/Word/WordDocumentGenerator.cs
- DocumentService/Pdf/PdfDocumentGenerator.cs
🧰 Additional context used
🧠 Learnings (47)
📓 Common learnings
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#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#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#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#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, 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#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#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#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#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.
OsmoDoc.API/OsmoDoc.API.csproj (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#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/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.
OsmoDoc.API/DotEnv.cs (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.html (11)
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#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#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#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.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
OsmoDoc.API/Helpers/AuthenticationHelper.cs (9)
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#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, 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#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#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.
.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.API/OsmoDoc.API.sln (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#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#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/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.
docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentType.html (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
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.
OsmoDoc/Pdf/Models/DocumentData.cs (9)
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.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentData.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#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
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/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/Pdf/Models/ContentMetaData.cs (8)
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#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
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.
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.
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/OsmoDocWord.html (8)
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#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#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#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 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/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.
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.
docs/site/manifest.json (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#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.
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/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/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#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.
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#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
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#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.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#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#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/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.
.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."
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.
OsmoDoc.sln (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#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#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/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.
OsmoDoc/Word/Models/Enums.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#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
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#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#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#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: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/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.API/Program.cs (11)
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#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#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, 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#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#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#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/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.
docs/site/10.0.2/api/OsmoDoc.Word.Models.DocumentData.html (6)
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#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
docs/site/10.0.2/api/toc.html (2)
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.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.
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.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.
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.
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/Word/Models/ContentData.cs (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 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.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
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#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/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.
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#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.
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#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.
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.
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.
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#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: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/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.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/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#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/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#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.
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#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/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#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
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.
🧬 Code Graph Analysis (5)
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.API/Program.cs (4)
OsmoDoc.API/DotEnv.cs (2)
DotEnv(3-35)Load(5-33)OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs (1)
OsmoDocPdfConfig(3-7)OsmoDoc/Services/RedisTokenStoreService.cs (2)
RedisTokenStoreService(9-42)RedisTokenStoreService(14-17)OsmoDoc.API/Models/BaseResponse.cs (1)
ModelValidationBadRequest(22-38)
OsmoDoc.API/Models/PdfGenerationRequestDTO.cs (1)
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/Word/WordDocumentGenerator.cs (4)
OsmoDoc/Word/Models/DocumentData.cs (1)
DocumentData(11-28)OsmoDoc/Pdf/Models/DocumentData.cs (1)
DocumentData(7-10)OsmoDoc/Word/Models/TableData.cs (1)
TableData(9-22)OsmoDoc/Word/Models/ImageData.cs (1)
ImageData(13-39)
🪛 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 (42)
OsmoDoc.API/Models/BaseResponse.cs (2)
1-3: LGTM: Namespace change aligns with project refactoring.The namespace change from
DocumentService.API.ModelstoOsmoDoc.API.Modelsis consistent with the broader project migration objectives.
24-37: LGTM: Improved model validation error handling.The refactored
ModelValidationErrorResponsemethod implements robust error extraction with proper null safety:
- Safely filters ModelState entries using null checks
- Correctly uses null-forgiving operator after validation
- Provides appropriate fallback message
- Returns consistent BaseResponse format
The LINQ implementation efficiently handles edge cases and provides clear error messaging.
.gitignore (1)
355-357: LGTM! Good practice for temporary file management.Adding the
Temp/directory to.gitignoreis appropriate for a document generation service that creates temporary files during processing. This prevents temporary files from being tracked in version control, which aligns with the Docker mount volume setup mentioned in the AI summary.CONTRIBUTING.md (1)
1-155: LGTM! Comprehensive and consistent project renaming.The renaming from "document-service" to "osmodoc" has been applied consistently throughout the contributing guidelines, including URLs, Stack Overflow tags, and project references. This aligns with the broader project restructuring mentioned in the PR objectives.
OsmoDoc/Word/Models/ImageData.cs (2)
6-11: Well-defined enum for image source types.The
ImageSourceTypeenum clearly defines the supported image sources (Base64, LocalFile, Url) with appropriate numeric values. This provides a clean abstraction for different image input methods.
13-38: Excellent validation implementation.The
ImageDataclass demonstrates good validation practices:
- Proper use of data annotations for required fields
- Custom validation logic that enforces business rules (ImageExtension required for Base64)
- Descriptive error messages that will help API consumers
- Defensive programming with
string.EmptyinitializationThis implementation aligns well with the enhanced image handling capabilities mentioned in the PR objectives.
OsmoDoc.API/OsmoDoc.API.csproj (2)
16-16: LGTM! Project reference updated for migration.The project reference has been correctly updated from
DocumentService.csprojtoOsmoDoc.csproj, which is consistent with the broader project restructuring from DocumentService to OsmoDoc.
11-11: Redis client package version is current and secureVerified that StackExchange.Redis v2.8.41 (released June 10, 2025) is the latest available and has no known security advisories for the client library. No changes required—you can safely proceed with this dependency update.
OsmoDoc.API/OsmoDoc.API.sln (1)
6-6: LGTM! Solution file updated for project renaming.The project entry has been correctly updated from "DocumentService.API" to "OsmoDoc.API", maintaining consistency with the broader project restructuring from DocumentService to OsmoDoc.
OsmoDoc.API/DotEnv.cs (1)
12-32: Skip blank / comment lines and avoid polluting the environment
.envfiles frequently contain empty rows or comment lines beginning with#.
Today those lines fall through and end up creating zero-length or#FOOvariables.- foreach (string line in File.ReadAllLines(filePath)) + foreach (var rawLine in File.ReadAllLines(filePath)) { - // Check if the line contains '=' - int equalsIndex = line.IndexOf('='); + var line = rawLine.Trim(); + + // Ignore blank lines and comments + if (string.IsNullOrEmpty(line) || line.StartsWith('#')) + continue; + + // Split on the first '=' + int equalsIndex = line.IndexOf('=');Keeps the current behaviour intact while hardening the parser.
[ suggest_optional_refactor ]docs/site/10.0.2/api/OsmoDoc.Word.Models.html (2)
8-12: Namespace rename applied consistently – looks goodNo issues spotted with the DocFX metadata/title changes.
70-92: Anchors & xref targets updated correctly
data-uid, heading IDs, and all xref hyperlinks now point toOsmoDoc.*. All resolved fine.docs/site/manifest.json (2)
3-4: Good move to a relativesource_base_pathSwitching to
./improves portability across build agents and local environments.
8-12: Manifest entries renamed – verify DocFX link validityEntries now reference
OsmoDoc.*. Just rundocfx serveonce to ensure no broken links slipped through.Also applies to: 18-22, 28-32, 38-42, 48-52, 58-62, 68-72, 78-82
docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentData.html (1)
70-110: API doc namespace update verifiedAll
data-uid, headings, and namespace/assembly references match the newOsmoDocnomenclature.docs/site/10.0.2/api/OsmoDoc.Word.Models.ParentBody.html (1)
70-101: Enum documentation correctly migratedUIDs, anchors, and field IDs now align with
OsmoDoc. No functional problems observed.OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs (1)
1-7: LGTM! Clean configuration class implementation.The static configuration class follows the established pattern for cross-platform compatibility, allowing runtime configuration of the wkhtmltopdf binary path as needed.
docs/site/10.0.2/api/OsmoDoc.Word.Models.TableData.html (1)
70-108: LGTM! Consistent namespace documentation updates.The documentation updates correctly reflect the namespace rename from DocumentService.Word.Models to OsmoDoc.Word.Models. All metadata references and assembly names have been updated consistently.
OsmoDoc.API/Models/RevokeTokenRequestDTO.cs (1)
1-9: LGTM! Well-structured DTO following established patterns.The DTO properly implements validation attributes and follows the project's pattern of initializing properties to prevent null reference issues. This aligns well with the Redis-based token management system.
.env.example (1)
1-10: LGTM! Comprehensive environment configuration.The environment variables properly support the Redis-based token management system and provide clear guidance for secure JWT key configuration. The Redis settings align well with the containerized deployment approach.
OsmoDoc/OsmoDoc.csproj (1)
8-18: LGTM! Well-structured package metadata.The NuGet package metadata is comprehensive and properly configured for distribution. The package information clearly describes the library's purpose and includes appropriate tags and licensing.
OsmoDoc.sln (1)
6-8: LGTM! Clean project renaming.The solution file has been correctly updated to reflect the project renaming from DocumentService to OsmoDoc. The project GUIDs are preserved and the paths are updated appropriately.
OsmoDoc.API/Models/LoginRequestDTO.cs (1)
1-10: LGTM! Well-structured DTO with proper validation.The LoginRequestDTO follows ASP.NET Core best practices with appropriate validation attributes and defensive initialization. The data annotations will handle validation automatically.
OsmoDoc/Word/Models/TableData.cs (1)
1-22: LGTM! Clean model class following team patterns.The TableData class is well-structured with proper XML documentation and follows the team's established pattern of initializing list properties with
= new(). The model appropriately represents table data for Word documents.docs/site/10.0.2/api/toc.html (1)
17-43: LGTM! Consistent documentation namespace updates.The HTML documentation has been correctly updated to reflect the namespace renaming from DocumentService.Word to OsmoDoc.Word. All changes are consistent and maintain the existing navigation structure.
OsmoDoc/Word/Models/DocumentData.cs (1)
11-28: LGTM! Well-structured model class following team patterns.The DocumentData class follows the team's established pattern of initializing list properties with
= new()and provides comprehensive XML documentation. The addition of Images property extends the previous functionality appropriately.OsmoDoc.API/Helpers/CommonMethodsHelper.cs (2)
3-3: LGTM: Namespace migration completed correctly.The namespace change from
DocumentService.API.HelperstoOsmoDoc.API.Helpersaligns with the project-wide migration to OsmoDoc branding.
9-12: Excellent addition of input validation.The validation logic properly guards against null, empty, or whitespace file paths before processing. The exception message is descriptive and follows .NET conventions.
docs/site/xrefmap.yml (1)
4-195: LGTM: Comprehensive cross-reference map migration.The systematic update of all UIDs, names, hrefs, commentIds, and fullNames from
DocumentService.WordtoOsmoDoc.Wordensures proper documentation cross-referencing for the namespace migration. All entries have been updated consistently.OsmoDoc/Word/Models/Enums.cs (1)
1-31: LGTM: Well-structured enums with excellent documentation.The new enums are properly documented and follow good practices with explicit value assignments. The simplified
ContentType(only Text) appears intentional for the current OpenXML migration phase.docs/site/10.0.2/api/OsmoDoc.Word.Models.DocumentData.html (1)
70-195: LGTM: Systematic documentation namespace migration.All references in the HTML documentation have been consistently updated from
DocumentService.Word.ModelstoOsmoDoc.Word.Models, including data-uid attributes, namespace links, assembly references, and property type references.docs/site/10.0.2/api/OsmoDoc.Word.WordDocumentGenerator.html (1)
70-184: LGTM: Complete documentation namespace migration.All references in the WordDocumentGenerator HTML documentation have been systematically updated from
DocumentService.WordtoOsmoDoc.Word, including class identifiers, namespace links, assembly references, and method parameter type references.OsmoDoc.API/Models/PdfGenerationRequestDTO.cs (1)
6-12: LGTM! Well-structured DTO with proper validation.The DTO is well-designed with appropriate validation attributes, defensive initialization of
DocumentData, and clear nullable annotations for optional properties.OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs (1)
6-11: LGTM! Clean interface design for Redis token management.The interface follows proper async patterns with CancellationToken support. Based on the learnings, I understand the implementation will use
ThrowIfCancellationRequested()since StackExchange.Redis doesn't directly support cancellation tokens.Dockerfile (1)
5-52: LGTM! Production-ready Dockerfile with proper optimizations.The Dockerfile is well-configured for production with Release builds, consolidated package installation with cleanup, and production-only npm dependencies. The port configuration and project references are correctly updated for the OsmoDoc rename.
OsmoDoc.API/Program.cs (1)
46-141: Redis token management implementation looks solid.The Redis integration and JWT authentication setup properly implement the hybrid token management approach described in the learnings, with non-expiring tokens validated against Redis for manual revocation support.
OsmoDoc/Services/RedisTokenStoreService.cs (1)
1-42: Implementation aligns with the established token management pattern.The Redis token store service correctly implements the hybrid JWT + Redis approach as established in previous PRs. The cancellation token handling follows the recommended pattern for StackExchange.Redis, and the deliberate absence of TTL aligns with your manual token lifecycle management preference.
OsmoDoc.API/Controllers/LoginController.cs (1)
51-56: Add null check for request parameter.Consistent with other controllers, validate the request parameter before use.
public async Task<ActionResult<BaseResponse>> RevokeToken([FromBody] RevokeTokenRequestDTO request) { BaseResponse response = new BaseResponse(ResponseStatus.Fail); try { + if (request == null) + { + throw new BadHttpRequestException("Request body cannot be null"); + } await this._tokenStoreService.RevokeTokenAsync(request.Token, this.HttpContext.RequestAborted);⛔ Skipped due to learnings
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.API/Controllers/PdfController.cs (1)
27-151: Well-structured error handling and resource managementThe implementation correctly validates request parameters, configuration values, and includes proper cleanup of temporary files in the finally block. The async pattern and comprehensive exception handling are appropriate.
Based on your preferences from previous reviews, the stack trace logging and cleanup scope (limited to temp files only) align with the intended NuGet package usage pattern.
OsmoDoc/Pdf/PdfDocumentGenerator.cs (1)
23-79: Robust async PDF generation implementationThe method includes comprehensive parameter validation, proper EJS template handling, and ensures cleanup through the finally block. The cross-platform WkhtmltopdfPath configuration check aligns with the intended flexibility.
OsmoDoc/Word/WordDocumentGenerator.cs (2)
147-201: Excellent handling of OpenXML text splitting complexityThe implementation correctly addresses the OpenXML issue where placeholders can be split across multiple Text elements. The approach of concatenating all text, performing replacements, and consolidating into a single Text element ensures reliable placeholder replacement.
358-365: Verify image placeholder matching logicThe code searches for image placeholders by matching the
Descriptionproperty ofDocProperties. Please ensure this is the correct property where placeholder names are stored in your Word templates.If image placeholders are stored differently in your templates (e.g., in the
NameorTitleproperty), you may need to adjust the matching logic accordingly.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
OsmoDoc/Pdf/PdfDocumentGenerator.cs (1)
18-19: Fix incorrect class name in documentation comment.The documentation comment mentions "WordDocumentGenerator" but this is the PdfDocumentGenerator class.
- /// Configures logging for the WordDocumentGenerator + /// Configures logging for the PdfDocumentGenerator
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
OsmoDoc/Pdf/PdfDocumentGenerator.cs(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
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#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#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#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#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#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#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#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#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#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/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#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#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.
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.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.
⏰ 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 (8)
OsmoDoc/Pdf/PdfDocumentGenerator.cs (8)
35-35: LGTM: Well-designed method signature with comprehensive parameters.The async method signature properly handles all required parameters for PDF generation, including optional EJS template support and serialized data.
37-55: Excellent input validation with proper platform-specific handling.The validation logic correctly handles:
- Null checks for required parameters
- Platform-specific wkhtmltopdf path validation (not required on Linux)
- File existence verification
This aligns with the cross-platform compatibility objectives.
65-91: Robust error handling with proper resource cleanup.The try-finally block ensures temporary resources are cleaned up even if exceptions occur during PDF generation. The cleanup logic properly handles both EJS conversion artifacts and modified HTML directories.
93-118: Effective placeholder replacement with secure temporary file handling.The method correctly:
- Replaces placeholders using the expected
{{placeholder}}syntax- Creates unique temporary directories using GUID to avoid conflicts
- Returns both file path and directory for proper cleanup
120-174: Comprehensive cross-platform PDF conversion implementation.The method properly handles platform differences:
- Uses system wkhtmltopdf binary on Linux
- Validates and uses explicit path on Windows
- Includes proper error handling with exit code checking
- Async process execution with proper output/error capture
176-236: Excellent EJS to HTML conversion with cross-platform npx support.Based on the learned context, this correctly implements the npx cross-platform compatibility changes discussed in PR #54. The implementation properly handles:
- JSON validation for EJS data
- Platform-specific command execution
- Temporary file management
- Error handling with meaningful messages
251-265: Perfect implementation of cross-platform EJS arguments.This method correctly implements the exact npx compatibility solution from the learned context:
- Windows: Uses
/C npx ejswith cmd.exe- Linux: Uses
ejsas first argument with npx directly- Proper exception for unsupported platforms
267-296: Robust cleanup implementation with proper exception handling.The cleanup logic correctly:
- Handles both EJS conversion artifacts and modified HTML directories
- Uses try-catch blocks to prevent cleanup failures from masking original exceptions
- Logs cleanup failures using the configured logger without throwing
- Follows the learned pattern of limiting cleanup scope to intermediate files only
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (5)
OsmoDoc.API/Controllers/WordController.cs (2)
40-48: Consider leveraging ASP.NET Core's built-in model validation.While the explicit null checks provide clear error messages, based on your previous preference for ASP.NET Core's built-in model validation system (using
[Required]attributes), you might want to consider using model validation attributes on theWordGenerationRequestDTOproperties instead of explicit null checks.
85-85: Remove redundant boolean comparison.The explicit
== truecomparison is unnecessary sinceAny()already returns a boolean.- if (request.DocumentData.ImagesData.Any(img => string.IsNullOrEmpty(img.Data)) == true) + if (request.DocumentData.ImagesData.Any(img => string.IsNullOrEmpty(img.Data)))OsmoDoc/Word/WordDocumentGenerator.cs (3)
32-32: Consider thread safety for the static logger field.The static
_loggerfield could have thread safety issues ifConfigureLoggingis called concurrently from multiple threads after the class is already in use.Consider making the logger field volatile or using a concurrent approach:
-private static ILogger _logger = NullLogger.Instance; +private static volatile ILogger _logger = NullLogger.Instance;Or use a more robust thread-safe approach with lazy initialization if needed.
49-49: Consider using async naming convention.The method signature doesn't follow the standard async naming convention.
-public async static Task GenerateDocumentByTemplate(string templateFilePath, DocumentData documentData, string outputFilePath) +public static async Task GenerateDocumentByTemplateAsync(string templateFilePath, DocumentData documentData, string outputFilePath)
412-412: Consider more descriptive temporary file naming.Using
GetTempFileName()creates files with random names. Consider using a more descriptive pattern for easier debugging and log correlation.-string tempFilePath = IOPath.GetTempFileName(); +string tempFilePath = IOPath.Combine(IOPath.GetTempPath(), $"osmodoc_img_{Guid.NewGuid()}.tmp");
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
OsmoDoc.API/Controllers/PdfController.cs(1 hunks)OsmoDoc.API/Controllers/WordController.cs(1 hunks)OsmoDoc.API/appsettings.json(1 hunks)OsmoDoc/Word/WordDocumentGenerator.cs(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- OsmoDoc.API/appsettings.json
🚧 Files skipped from review as they are similar to previous changes (1)
- OsmoDoc.API/Controllers/PdfController.cs
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
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#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#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#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#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#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#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#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#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#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/Controllers/WordController.cs (10)
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#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#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.
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#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T10:16:58.800Z
Learning: In OpenXML SDK Word document processing, text content can be split across multiple Text elements even when it appears as continuous text in the document. This happens due to formatting, spell checking, grammar checking, copy-paste operations, and other Word features. When replacing placeholders like "{InvoiceNo}", a simple Contains() check on individual Text elements will fail if the placeholder spans multiple elements. The solution requires concatenating all text content, performing replacement on the full string, and then rebuilding the Text elements appropriately.
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.
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.
🧬 Code Graph Analysis (1)
OsmoDoc/Word/WordDocumentGenerator.cs (4)
OsmoDoc/Word/Models/DocumentData.cs (1)
DocumentData(11-28)OsmoDoc/Pdf/Models/DocumentData.cs (1)
DocumentData(7-10)OsmoDoc/Word/Models/TableData.cs (1)
TableData(9-22)OsmoDoc/Word/Models/ImageData.cs (1)
ImageData(13-39)
⏰ 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 (7)
OsmoDoc.API/Controllers/WordController.cs (3)
99-103: LGTM: Proper async document generation implementation.The async call to
WordDocumentGenerator.GenerateDocumentByTemplatecorrectly implements the new asynchronous document generation pattern, which aligns with the PR objective of completing the OpenXML implementation.
146-173: LGTM: Consistent resource cleanup implementation.The cleanup logic properly follows the established pattern from other controllers in the project, with conditional cleanup based on configuration and proper error handling during file deletion operations.
91-96: Images property mapping is compatible
BothDocumentData.ImagesandWordGenerationRequestDTO.ImagesDataare of typeList<ImageData>, so assigningImages = request.DocumentData.ImagesDatais valid and no additional mapping is required.Locations verified:
- OsmoDoc.API/Models/WordGenerationRequestDTO.cs (line 19)
- OsmoDoc/Word/Models/DocumentData.cs (line 27)
OsmoDoc/Word/WordDocumentGenerator.cs (4)
152-201: Excellent implementation of OpenXML text replacement logic.This implementation correctly handles the OpenXML challenge where text content can be split across multiple Text elements. The approach of concatenating all text, performing replacement, then rebuilding the structure is exactly right and aligns with the learning about this specific OpenXML complexity.
466-470: HttpClient usage is consistent with team preference.The code creates a new HttpClient instance per request, which aligns with the team's established preference from previous discussions in PR #41. While not optimal for performance, it's consistent with the project's current approach.
67-104: Excellent error handling and logging implementation.The error handling properly logs the failure with context and re-throws for consumers to handle. This follows good practices for library code where callers should decide how to handle failures.
374-374: Potential null reference exception.The code assumes
blip.Embed!is not null after checkingblip.Embed?.Value == null, but this could still throw ifblip.Embedbecomes null between the check and usage.-OpenXmlPart imagePart = mainPart.GetPartById(blip.Embed!); +string embedValue = blip.Embed.Value; +OpenXmlPart imagePart = mainPart.GetPartById(embedValue);⛔ Skipped due to learnings
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.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
OsmoDoc.API/DotEnv.cs (1)
7-18: Consider performance optimization for directory traversal.The current implementation creates DirectoryInfo objects for each directory level, which could be optimized using string operations for better performance.
public static void LoadEnvFile(string fileName = ".env") { if (string.IsNullOrWhiteSpace(fileName)) throw new ArgumentException("fileName cannot be null or empty", nameof(fileName)); - DirectoryInfo? dir = new DirectoryInfo(Directory.GetCurrentDirectory()); - - while (dir != null) + string currentDir = Directory.GetCurrentDirectory(); + + while (!string.IsNullOrEmpty(currentDir)) { - string envPath = Path.Combine(dir.FullName, fileName); + string envPath = Path.Combine(currentDir, fileName); if (File.Exists(envPath)) { Load(envPath); return; } - dir = dir.Parent; + string? parentDir = Directory.GetParent(currentDir)?.FullName; + if (parentDir == currentDir) // Reached root directory + break; + currentDir = parentDir ?? string.Empty; } throw new FileNotFoundException($"{fileName} file not found"); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
OsmoDoc.API/DotEnv.cs(1 hunks)OsmoDoc.API/Program.cs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- OsmoDoc.API/Program.cs
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
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#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#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#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#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#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#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#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#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#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.
⏰ 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)
osm-Jatin
force-pushed
the
refactor/optimize
branch
from
3cd9add to
e275e90
Compare
osm-Jatin
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Task
REST-1648
Description
Summary by CodeRabbit
New Features
Improvements
Refactor
Documentation
Chores