Skip to content

1.15.479 #744

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
FriedrichWeinmann merged 3 commits into from
Oct 27, 2026
Merged

1.15.479 #744

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ce69271
in memory logging
FriedrichWeinmann Oct 25, 2026
958c54d
adding inmemory logging provider
FriedrichWeinmann Oct 27, 2026
48143e5
Merge pull request #743 from PowershellFrameworkCollective/tuning_fixes
FriedrichWeinmann Oct 27, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
89 changes: 89 additions & 0 deletions .github/skills/static-code-review/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
---
name: static-code-review
description: 'Perform evidence-based static code reviews for bugs, technical errors, security vulnerabilities, and performance or scaling risks without executing project code. Use when asked to review, audit, inspect, or assess a PowerShell module, Azure integration, build pipeline, or repository through read-only analysis.'
argument-hint: 'Optionally specify files, folders, categories, or a strict no-execution constraint'
user-invocable: true
---

# Static Code Review

Review code through read-only analysis and report actionable findings before summaries. Prioritize defects that affect correctness, safety, security, or behavior at scale.

## Scope And Constraints

- Respect the files, symbols, categories, and depth requested by the user.
- When no scope is supplied, cover all functions, module initialization, manifests, build and release paths, and relevant tests.
- Do not edit files during a review unless the user separately asks for fixes.
- In strict no-execution mode, do not run or import project code, scripts, modules, tests, builds, linters, analyzers, parsers, package managers, or cloud operations.
- In strict no-execution mode, use only read-only file listing, file reading, text or semantic search, read-only exploration agents, repository history when needed, and authoritative documentation lookup.

## Review Procedure

1. Establish the review boundary and execution constraints from the request.
2. Inventory the smallest set of public entry points that represents the requested surface.
3. Trace each entry point to the code that directly constructs requests, mutates state, transforms data, resolves identity or configuration, or controls error and confirmation behavior.
4. Inspect the module loader, manifest, build pipeline, and published-artifact assembly path. Distinguish source-tree behavior from generated release behavior.
5. Inspect tests for behavioral coverage of the reviewed paths. Do not treat a missing test as a defect unless it leaves a concrete finding unprotected.
6. Compare external request paths, API versions, body shapes, query parameters, enumerations, and response assumptions with authoritative vendor documentation.
7. Search for security-sensitive behavior: destructive operations, confirmation bypasses, credential or token exposure, command or expression evaluation, mutable remote scripts, untrusted input crossing trust boundaries, and overly broad exports.
8. Search for scaling behavior: repeated remote enumeration, per-item authentication or resolution, client-side filtering after broad list calls, missing pagination handling, unbounded materialization, and nested work whose cost grows with input size.
9. Validate every candidate against nearby code, language semantics, build transformations, and external contracts. Remove findings that depend only on style, convention, or an unverified assumption.
10. Report findings in descending severity with exact file and line references, impact, static evidence, and the condition that triggers the problem.

## PowerShell Checks

- Verify advanced functions that mutate state declare `SupportsShouldProcess` and pass `$PSCmdlet` through wrappers that implement `ShouldProcess`.
- Trace whether `-WhatIf` and `-Confirm` reach the actual mutating operation rather than relying on help text or naming.
- Check parameter mandatory status, parameter sets, validation attributes, aliases, default values, pipeline binding, and variable mutation across `begin`, `process`, and `end`.
- Inspect list commands for wildcard routing, pagination, server-side versus client-side filtering, and subscription-wide enumeration.
- Inspect manifests together with `Export-ModuleMember` and build-time manifest rewriting before claiming that internal functions are exported.
- Inspect build scripts for incorrect source paths, omitted classes or enums, cleanup that removes uncompiled sources, and differences between local and published modules.
- Do not claim that accessing a property such as `$null.Keys` throws unless strict mode or the actual runtime semantics make that true.

## API Interaction Checks

- Check request URI construction for missing resource segments, accidental collection endpoints, invalid interpolation, and path/query values derived from unchecked input.
- Check request bodies against the selected API version, including property nesting, read-only fields, enum values, conditional properties, and service-specific types.
- Verify service or cloud mappings are propagated to every request and helper call rather than replaced with hard-coded defaults.
- Check converters for assumptions about resource ID shape, null input, collection responses, and property availability.

## Candidate Validation

Before reporting a finding, answer all of the following:

- What exact input, configuration, or call path reaches it?
- What observable failure, security impact, or scaling cost follows?
- Which line directly causes the behavior?
- Is the claim confirmed by local language semantics or an authoritative external contract?
- Could a wrapper, build step, generated artifact, dependency behavior, or later guard invalidate the claim?
- Is this a defect rather than a preference, hardening suggestion, or documentation issue?

If any answer is missing, investigate one nearby hop or downgrade the item to an explicit risk or open question. Do not present speculation as a confirmed defect.

## Severity

- **Critical**: Prevents parsing, loading, building, or publishing the primary artifact; enables direct compromise; or causes catastrophic unintended mutation.
- **High**: Breaks a core operation, bypasses an expected safety control, creates a practical security vulnerability, or sends materially invalid external requests.
- **Medium**: Breaks an optional feature or common edge case, creates misleading behavior with operational impact, or scales poorly under realistic load.
- **Low**: Limited correctness defect, hardening opportunity, or performance issue with a narrow trigger and small impact.

Do not inflate severity merely because code calls a cloud API or performs deletion. Base severity on reachability and impact.

## Reporting Format

Lead with findings, ordered by severity. For each finding include:

1. A concise impact-oriented title.
2. A clickable file and line reference.
3. The triggering path or input.
4. The resulting behavior and why it matters.
5. The decisive static evidence or external contract.

After findings, include only relevant open questions, then a short review summary covering:

- areas reviewed;
- whether confirmed security or scaling defects were found;
- test gaps tied to reported findings;
- the no-execution limitation.

If no actionable findings remain after validation, say so clearly and identify residual risks or unreviewed boundaries. Avoid padding the report with style observations.
2 changes: 1 addition & 1 deletion PSFramework/PSFramework.psd1
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
RootModule = 'PSFramework.psm1'

# Version number of this module.
ModuleVersion = '1.15.472'
ModuleVersion = '1.15.479'

# ID used to uniquely identify this module
GUID = '8028b914-132b-431f-baa9-94a6952f21ff'
Expand Down
Binary file modified PSFramework/bin/PSFramework.dll
View file
Open in desktop
Binary file not shown.
Binary file modified PSFramework/bin/PSFramework.pdb
View file
Open in desktop
Binary file not shown.
148 changes: 148 additions & 0 deletions PSFramework/bin/PSFramework.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -252,6 +252,16 @@
<param name="key">The key of the entry</param>
<returns>The value matching the key</returns>
</member>
<member name="M:PSFramework.Caching.CacheMemoryConcurrent.TryGetValue(System.Object,System.Object@)">
<summary>
A threadsafe way to retrieve content from the cache.
This is the only way to do so and be able to distinguish between "Not cached" and "Cache entry exists, but is null".
As such this method is of limited use within PowerShell.
</summary>
<param name="Key">The key to retrieve the cached value for.</param>
<param name="Value">The value retrieved</param>
<returns>Whether retrieval was successful.</returns>
</member>
<member name="T:PSFramework.Caching.CachedData">
<summary>
A cache entry
Expand Down Expand Up @@ -1532,6 +1542,11 @@
</summary>
<param name="Message">The message to write</param>
</member>
<member name="M:PSFramework.Commands.WritePSFMessageCommand.WriteWarningOrError">
<summary>
Writes a warning or error level message by the preferred color, if any.
</summary>
</member>
<member name="M:PSFramework.Commands.WritePSFMessageCommand.ResolveDefaultColor">
<summary>
Calculates the default color a message should have
Expand Down Expand Up @@ -3639,6 +3654,119 @@
The logging has been fully stopped
</summary>
</member>
<member name="T:PSFramework.Logging.MemoryLog">
<summary>
Contains the log entries retained by an in-memory log provider instance.
</summary>
</member>
<member name="F:PSFramework.Logging.MemoryLog.Name">
<summary>
The name of the memory log
</summary>
</member>
<member name="F:PSFramework.Logging.MemoryLog.MaxCount">
<summary>
Maximum number of messages before the oldest entries get forgotten.
</summary>
</member>
<member name="F:PSFramework.Logging.MemoryLog.MaxAge">
<summary>
Maximum age of log entries before they get removed.
</summary>
</member>
<member name="F:PSFramework.Logging.MemoryLog.ShouldArchive">
<summary>
Should the memory log be archived when retired?
Otherwise, it will be lost on retirement.
</summary>
</member>
<member name="F:PSFramework.Logging.MemoryLog.ArchivePath">
<summary>
Path to where logs should be written when retired.
LogEntries will be written as binary data blob and can be read in with Import-PSFClixml.
</summary>
</member>
<member name="F:PSFramework.Logging.MemoryLog.RetireWithRunspace">
<summary>
When the following runspace no longer exists, automatically retire this log.
</summary>
</member>
<member name="M:PSFramework.Logging.MemoryLog.#ctor(System.String)">
<summary>
Create a new in-memory log
</summary>
<param name="Name">Name of the log to create. Retires previous logs with this name.</param>
</member>
<member name="F:PSFramework.Logging.MemoryLog.Started">
<summary>
When the MemoryLog was started.
</summary>
</member>
<member name="P:PSFramework.Logging.MemoryLog.Stopped">
<summary>
When the MemoryLog was closed.
</summary>
</member>
<member name="F:PSFramework.Logging.MemoryLog.Archived">
<summary>
Whether the log has been archived
</summary>
</member>
<member name="F:PSFramework.Logging.MemoryLog.ID">
<summary>
ID of the MemoryLog, to differentiate multiple archived logs with the same name
</summary>
</member>
<member name="F:PSFramework.Logging.MemoryLog._Messages">
<summary>
Messages that are logged
</summary>
</member>
<member name="P:PSFramework.Logging.MemoryLog.Count">
<summary>
How many messages are in the log
</summary>
</member>
<member name="P:PSFramework.Logging.MemoryLog.Messages">
<summary>
The messages in the log
</summary>
</member>
<member name="M:PSFramework.Logging.MemoryLog.Add(PSFramework.Message.LogEntry)">
<summary>
Add a new log entry to the log
</summary>
<param name="Entry">The data to log</param>
</member>
<member name="M:PSFramework.Logging.MemoryLog.PurgeNoLock">
<summary>
Remove all invalid log entries in the Log.
Not threadsafe.
</summary>
</member>
<member name="M:PSFramework.Logging.MemoryLog.Purge">
<summary>
Remove all invalid log entries in the Log.
Threadsafe.
</summary>
</member>
<member name="M:PSFramework.Logging.MemoryLog.Get">
<summary>
Retrieve all log entries.
</summary>
<returns>All logged entries.</returns>
</member>
<member name="M:PSFramework.Logging.MemoryLog.Clear">
<summary>
Remove all log entries from the Log
</summary>
</member>
<member name="M:PSFramework.Logging.MemoryLog.Retire">
<summary>
Retire the current Log.
This unlists it from the log tracker and executes all "on archive" settings.
</summary>
</member>
<member name="T:PSFramework.Logging.Provider">
<summary>
Class containing all information/content needed for a logging provider
Expand Down Expand Up @@ -4673,6 +4801,16 @@
<param name="ErrorStack">Whether to use the error record for logging the callstack</param>
<returns>The entry that is being written</returns>
</member>
<member name="F:PSFramework.Message.LogHost.InMemoryLogs">
<summary>
The currently active InMemory logs of the inmemory Logging Provider
</summary>
</member>
<member name="F:PSFramework.Message.LogHost.InMemoryLogsArchive">
<summary>
The list of archived InMemory logs of the inmemory Logging Provider
</summary>
</member>
<member name="T:PSFramework.Message.MessageColorCondition">
<summary>
A rule object to change the default color of a message written to screen.
Expand Down Expand Up @@ -4939,6 +5077,16 @@
The color stuff gets written to the console in, when developer mode is enabled and the message would not have been written after all
</summary>
</member>
<member name="F:PSFramework.Message.MessageHost.WarningColor">
<summary>
The color with which to print warning messages on screen.
</summary>
</member>
<member name="F:PSFramework.Message.MessageHost.ErrorColor">
<summary>
The color with which to print error messages on screen.
</summary>
</member>
<member name="F:PSFramework.Message.MessageHost.DeveloperMode">
<summary>
Enables the developer mode. In this all messages are written to the console, in order to make it easier to troubleshoot issues.
Expand Down
10 changes: 10 additions & 0 deletions PSFramework/changelog.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,15 @@
# CHANGELOG

## 1.15.479 (2026-10-27)

- New: Logging Provider: inmemory - Writes messages to an in-memory list accessible through Get-PSFMessage.
- New: Config PSFramework.Message.ErrorColor - The color to use when writing error messages on screen. This prevents the use of the warning stream!
- New: Config PSFramework.Message.WarningColor - The color to use when writing warning messages on screen. This prevents the use of the warning stream!
- Upd: PSFCache - added a `TryGetValue` method to 100% reliably retrieve value when a $null cache might be a legal state.
- Upd: Get-PSFMessage - added `-LogName` parameter, allowing searching through the inmemory log of the new Logging Provider.
- Upd: Get-PSFMessage - added `-AsLog` parameter, retrieving the entire log object, rather than its messages.
- Upd: Clear-PSFMessage - add `-LogName` parameter, allowing the clearing of logs from the logs of the new Logging Provider

## 1.15.472 (2026-10-23)

- New: Logging Provider: Azure LogAnalytics V2 - sends logs to Log Analytics via Data Collection Rule
Expand Down
Loading