Severity: Info
File: src/Servy.Core/Logging/EventIds.cs lines 36–47
Finding
/// <summary>
/// Base ID for informational events emitted by setup or notification scripts.
/// Range: 1100 - 1199.
/// </summary>
public const int ScriptInfo = 1100;
/// <summary>
/// Base ID for warning events emitted by setup or notification scripts.
/// Range: 2100 - 2199.
/// </summary>
public const int ScriptWarning = 2100;
grep -rn "ScriptInfo\|ScriptWarning" over the entire source tree returns only the definitions in EventIds.cs itself — neither constant is referenced anywhere else.
The PowerShell scripts that would be the natural consumers (setup/taskschd/ServyFailureEmail.ps1, ServyFailureNotification.ps1, Get-ServyLastErrors.ps1) hardcode their event IDs as integer literals:
# ServyFailureEmail.ps1
$EVENT_ID_ERROR = 3103 # ScriptError + 3
$EVENT_ID_ERROR_DEP = 3104 # ScriptError + 4
…with no Info or Warning IDs ever emitted from the script side. So the ScriptInfo (1100) and ScriptWarning (2100) ranges are reserved on paper but not actually used.
Two related artefacts of the same drift:
-
The PS scripts contain the comment # Event ID Taxonomy (Refer to src/Servy.Core/Logging/EventIds.cs for updates) — but the literals they use (3103, 3104) are NOT defined as named constants in EventIds.cs. Updating EventIds.cs cannot in fact "update" what the scripts emit.
-
The wiki page Logging-&-Log-Rotation.md (lines 34–39) lists only Info / Warning / Error for the core service and Error for scripts — there is no row for Info (1100-1199) or Warning (2100-2199) for scripts. So the wiki silently agrees with the implementation that those ranges are unused, while EventIds.cs reserves them.
Suggested fix
One of the following:
-
Delete the dead constants if there is no plan to emit Info/Warning from scripts:
// Removed: ScriptInfo and ScriptWarning were never emitted by any script.
-
Wire them through to the PS scripts via a generated constants file (e.g. EventIds.psm1 produced by the build) so the scripts dot-source the same numeric source of truth, and convert the 3103/3104 literals to ${EventIds.ScriptError}+3 / +4.
-
Document the reserved-range intent in the XML comment so future maintainers don't think they're dead code:
/// <summary>
/// Reserved range 1100-1199 for informational script events.
/// Currently unused; reserved for future PowerShell-emitted Info events.
/// </summary>
public const int ScriptInfo = 1100;
Either way, the wiki Event-IDs table at Logging-&-Log-Rotation.md lines 34–39 should match the chosen approach.
Severity: Info
File:
src/Servy.Core/Logging/EventIds.cslines 36–47Finding
grep -rn "ScriptInfo\|ScriptWarning"over the entire source tree returns only the definitions inEventIds.csitself — neither constant is referenced anywhere else.The PowerShell scripts that would be the natural consumers (
setup/taskschd/ServyFailureEmail.ps1,ServyFailureNotification.ps1,Get-ServyLastErrors.ps1) hardcode their event IDs as integer literals:…with no
InfoorWarningIDs ever emitted from the script side. So theScriptInfo(1100) andScriptWarning(2100) ranges are reserved on paper but not actually used.Two related artefacts of the same drift:
The PS scripts contain the comment
# Event ID Taxonomy (Refer to src/Servy.Core/Logging/EventIds.cs for updates)— but the literals they use (3103,3104) are NOT defined as named constants in EventIds.cs. Updating EventIds.cs cannot in fact "update" what the scripts emit.The wiki page
Logging-&-Log-Rotation.md(lines 34–39) lists only Info / Warning / Error for the core service and Error for scripts — there is no row for Info (1100-1199) or Warning (2100-2199) for scripts. So the wiki silently agrees with the implementation that those ranges are unused, while EventIds.cs reserves them.Suggested fix
One of the following:
Delete the dead constants if there is no plan to emit Info/Warning from scripts:
// Removed: ScriptInfo and ScriptWarning were never emitted by any script.Wire them through to the PS scripts via a generated constants file (e.g.
EventIds.psm1produced by the build) so the scripts dot-source the same numeric source of truth, and convert the3103/3104literals to${EventIds.ScriptError}+3/+4.Document the reserved-range intent in the XML comment so future maintainers don't think they're dead code:
Either way, the wiki Event-IDs table at
Logging-&-Log-Rotation.mdlines 34–39 should match the chosen approach.