Reviewing files that changed from the base of the PR and between 9e6f4fd and 75976af.

• docs/middleware/logger.md (2 hunks)
• docs/whats_new.md (1 hunks)
• middleware/logger/config.go (3 hunks)
• middleware/logger/default_logger.go (1 hunks)
• middleware/logger/logger_test.go (1 hunks)

middleware/logger/default_logger.go (1)

18-21: Filter implementation looks correct.

This implementation adds a filter capability to the logger, allowing conditional logging based on request context. The placement at the beginning of the function is efficient as it avoids unnecessary processing for requests that should be skipped.

middleware/logger/logger_test.go (1)

174-224: Test structure looks good and effectively validates the filter functionality.

The test implementation properly verifies the filter functionality with two distinct test cases:

1. Verifying that logs are written for 404 status codes when filtered to only log those
2. Verifying that logs are not written for 200 status codes with the same filter

The tests correctly use a single middleware instance with both the filter and output capture, which accurately tests the filter's behavior.

middleware/logger/config.go (4)

23-27: Well-defined and properly documented feature addition.

The new Filter function field is well-designed and appropriately documented. It provides a clean extension point for conditionally logging requests based on custom logic, which addresses issue #3300 as mentioned in the PR objectives.

---

107-107: Appropriate default value for the new Filter field.

Setting the default value to nil is appropriate as it:

1. Maintains backward compatibility
2. Makes the feature optional
3. Follows the pattern of other optional function fields in the Config struct

---

136-138: Proper implementation of default value handling.

The implementation correctly follows the established pattern for handling default values in the configDefault function. This ensures consistent behavior when users don't explicitly provide a filter function.

---

23-27:

✅ Verification successful

Verify usage examples are provided in documentation.

The implementation looks good, but users might benefit from usage examples in the documentation showing how to implement filter functions for common scenarios (e.g., filtering by status code, path, etc.).

---

🏁 Script executed:

#!/bin/bash
# Check if examples are provided in the logger middleware documentation

# Look for Filter examples in docs
echo "Checking for Filter usage examples in documentation..."
grep -A 10 "Filter" docs/middleware/logger.md || echo "No Filter examples found in logger documentation"

# Check if the new feature is mentioned in what's new document
echo "Checking for mention in what's new document..."
grep -A 5 "Filter" docs/whats_new.md || echo "No mention of Filter in what's new document"

Length of output: 3951

---

Documentation Examples Verified

The Filter usage examples are clearly present in both docs/middleware/logger.md and docs/whats_new.md, demonstrating common scenarios like filtering based on status codes. No further action is required.

docs/middleware/logger.md (1)

161-161: Default Config Update: 'Filter' Initialization
The default configuration now initializes the Filter property to nil, which preserves the existing logging behavior when no filter is provided. This is consistent with the documented default in the configuration table.

Reviewing files that changed from the base of the PR and between 288edb2 and e2295e5.

• docs/middleware/logger.md (2 hunks)
• docs/whats_new.md (1 hunks)
• middleware/logger/logger_test.go (1 hunks)

• GitHub Check: unit (1.24.x, macos-13)
• GitHub Check: unit (1.24.x, windows-latest)
• GitHub Check: unit (1.23.x, windows-latest)
• GitHub Check: Compare
• GitHub Check: repeated

docs/whats_new.md (3)

915-916: Filter function documentation looks good.

The description clearly explains the purpose of the Filter function: it acts as a condition to determine whether a request should be logged.

---

935-940: Ensure this filter works as expected.

The comment and implementation align correctly. When the filter returns true (status != 200), the log will be written, which means logs will be skipped for 200 status codes.

---

928-932:

❓ Verification inconclusive

Inconsistent filtering logic.

This example has a potential issue with the filter logic. The comment says "log status code == 404", but the filter is returning true when the status is 404. The documentation at line 915-916 states that when the filter returns true, the log will be written. However, there seems to be confusion in past review comments about how this interacts with the defaultLogger.

Let's verify the implementation to ensure this works as expected:

---

🏁 Script executed:

#!/bin/bash
# Check how the Filter is used in the logger middleware implementation

# Search for places where the Filter is checked
rg -A 3 "if c\.Filter" middleware/logger/

Length of output: 43

---

Action Required: Verify Logger Filter Usage Consistency

The documentation snippet in docs/whats_new.md (lines 928–932) shows a logger configuration with a Filter function that returns true when the response status is equal to fiber.StatusNotFound. According to the docs (lines 915–916), returning true should trigger logging. However, our initial search for usage of c.Filter in the logger middleware (using rg -A 3 "if c\.Filter" middleware/logger/) did not produce any output.

Please manually verify the logger middleware implementation—especially within the logger.New configuration in the middleware/logger/ directory—to ensure that the Filter logic is applied as expected and interacts correctly with the default logger behavior.

middleware/logger/logger_test.go (2)

177-198: Test implementation for 404 filters looks good.

The test correctly sets up a logger middleware with a filter that only logs 404 responses, and then verifies that the output contains "404". This confirms the filter behavior works as expected.

---

200-225: Test implementation for 200 filter looks good.

The test correctly sets up a filter that logs everything except 200 responses, and verifies that the output does not contain "200". This confirms that the filter successfully skips logging OK responses.

docs/middleware/logger.md (2)

142-142: Filter property documentation looks good.

The description clearly explains what the Filter function does and how it affects logging behavior.

---

161-161: ⚠️ Potential issue

Fix syntax error in ConfigDefault.

There's a missing comma after nil in the ConfigDefault declaration, which would cause a compilation error.

- Filter         nil,
+ Filter:         nil,

Likely an incorrect or invalid review comment.