fix: replace serializers.Serializer with MonitoringDeviceDetailSerial…

[shakurah]

replace serializers.Serializer with MonitoringDeviceDetailSerializer in DeviceMetricView

Checklist

• I have read the OpenWISP Contributing Guidelines.
• I have manually tested the changes proposed in this pull request.
• I have written new test cases for new code and/or updated existing tests for changes to existing code.
• I have updated the documentation.

Reference to Existing Issue

Closes #716.

Description of Changes

The DeviceMetricView was using serializers.Serializer as its serializer_class
instead of MonitoringDeviceDetailSerializer. This caused drf-yasg to be unable to
infer the correct response schema, resulting in a generic example value being displayed
in the API documentation instead of the actual response fields.

Replacing it with MonitoringDeviceDetailSerializer allows drf-yasg to correctly
generate the schema for the endpoint, making the API documentation accurately reflect
the real response structure.

Screenshot

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

In openwisp_monitoring/device/api/views.py the DeviceMetricView.serializer_class was changed from rest_framework.serializers.Serializer to MonitoringDeviceDetailSerializer. The view now obtains device metric data via self.serializer_class(self.instance).data rather than directly instantiating MonitoringDeviceDetailSerializer. The import of serializers from rest_framework was removed because serializers.Serializer is no longer referenced.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: replacing serializers.Serializer with MonitoringDeviceDetailSerializer in DeviceMetricView, which is the core modification in this PR.
Description check	✅ Passed	The PR description follows the template with completed checklist items, clear reference to issue #716, detailed explanation of the problem and solution, and supporting screenshots.
Linked Issues check	✅ Passed	The PR successfully addresses issue #716 by replacing serializers.Serializer with MonitoringDeviceDetailSerializer, enabling drf-yasg to generate correct API documentation schema instead of showing generic placeholder fields.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to addressing issue #716: updating DeviceMetricView.serializer_class and removing unused serializers import. No unrelated modifications are present.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

📝 Coding Plan

• Generate coding plan for human review comments

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Tip

You can customize the tone of the review comments and chat replies.

Configure the tone_instructions setting to customize the tone of the review comments and chat replies. For example, you can set the tone to Act like a strict teacher, Act like a pirate and more.

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@openwisp_monitoring/device/api/views.py`:
- Line 123: The get() method currently bypasses the view's serializer_class by
calling MonitoringDeviceDetailSerializer(self.instance).data directly, causing
double-serialization or schema/runtime mismatches; change get() to use the
view's standard serializer retrieval (call self.get_serializer(self.instance))
and use its .data so both drf-yasg/schema generation and runtime responses rely
on the same serializer; ensure MonitoringApiViewMixin.get() behavior is
compatible (i.e., if it already calls get_serializer(), remove the hardcoded
MonitoringDeviceDetailSerializer usage) and keep serializer_class =
MonitoringDeviceDetailSerializer as the single source of truth.
- Line 123: The view sets serializer_class = MonitoringDeviceDetailSerializer
but assigns a plain JSON schema dict to schema, which drf-yasg ignores and
causes incorrect POST/GET/CSV documentation; fix by creating a drf-yasg
AutoSchema subclass (e.g., MonitoringDeviceAutoSchema) that returns the correct
per-method requestBody and responses using the existing JSON schema dict from
openwisp_monitoring/device/schema.py and the actual merged GET response (device
detail + charts) and CSV response (charts only), then set schema =
MonitoringDeviceAutoSchema() on the view; alternatively, if
MonitoringDeviceDetailSerializer is not used at runtime (the view hardcodes
serialization), remove serializer_class to avoid misleading docs.

---

ℹ️ Review info

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 331fca2 and b740dea.

📒 Files selected for processing (1)

• openwisp_monitoring/device/api/views.py

📜 Review details

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2026-02-21T18:44:28.852Z

Learnt from: dee077
Repo: openwisp/openwisp-monitoring PR: 738
File: openwisp_monitoring/device/api/views.py:263-281
Timestamp: 2026-02-21T18:44:28.852Z
Learning: In openwisp-monitoring, MonitoringIndoorCoordinatesList inherits organization scoping from the parent IndoorCoordinatesList (from openwisp-controller), which uses FilterByParentManaged mixin and filters by location_id in get_queryset(). The child class only overrides the queryset attribute to add monitoring-specific select_related fields; this pattern is safe as long as get_queryset() from the parent is not bypassed. During reviews, verify that MonitoringIndoorCoordinatesList continues to rely on the parent's get_queryset() and that any added select_related fields in the child do not alter the parent's filtering logic.

Applied to files:

• openwisp_monitoring/device/api/views.py

🧬 Code graph analysis (1)

openwisp_monitoring/device/api/views.py (1)

openwisp_monitoring/device/api/serializers.py (1)

• MonitoringDeviceDetailSerializer (109-110)

[coderabbitai]

♻️ Duplicate comments (1)

openwisp_monitoring/device/api/views.py (1)

123-158: Previously raised concerns remain unaddressed.

The serializer_class assignment is the right intent for fixing drf-yasg schema generation. However, two pre-existing issues flagged in prior review rounds are still present in the current code and are directly relevant to this change:

1. Double-serialization / decoupled serializer_class (line 154): get() still hardcodes MonitoringDeviceDetailSerializer(self.instance).data independently of serializer_class. If MonitoringApiViewMixin.get() calls self.get_serializer() internally, the serializer is invoked twice per request. At minimum, line 154 should use self.get_serializer(self.instance).data so the runtime path and the schema-inferred path share a single source of truth.

2. drf-yasg schema mismatch (lines 123, 125): The schema = schema assignment on line 125 is a plain dict (from openwisp_monitoring/device/schema.py), not a drf-yasg AutoSchema subclass — drf-yasg silently ignores it and falls back entirely to serializer_class. This means:

   • POST: Request body is documented as MonitoringDeviceDetailSerializer fields, but the actual POST payload is raw device-metrics JSON (NetJSON format).
   • GET: Response is documented as MonitoringDeviceDetailSerializer only, but the actual response is MonitoringDeviceDetailSerializer data merged with chart data (line 155–156).
   • CSV path (line 158): Returns only chart data, but is documented as MonitoringDeviceDetailSerializer.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@openwisp_monitoring/device/api/views.py` around lines 123 - 158, The view
still double-serializes and misleads drf-yasg: replace the hardcoded
MonitoringDeviceDetailSerializer(self.instance).data in get() with
self.get_serializer(self.instance).data (so the runtime serializer is the same
as serializer_class and used by any MonitoringApiViewMixin.get() path), and
replace the plain dict assigned to schema (the schema variable) with a proper
drf-yasg AutoSchema-compatible inspector or remove the dict so drf-yasg uses
serializer_class correctly; ensure GET responses documented reflect the merged
payload (MonitoringDeviceDetailSerializer + charts) and the CSV branch
documents/returns only chart data by updating the view’s schema implementation
to return the correct request/response schemas for get/post/csv.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@openwisp_monitoring/device/api/views.py`:
- Around line 123-158: The view still double-serializes and misleads drf-yasg:
replace the hardcoded MonitoringDeviceDetailSerializer(self.instance).data in
get() with self.get_serializer(self.instance).data (so the runtime serializer is
the same as serializer_class and used by any MonitoringApiViewMixin.get() path),
and replace the plain dict assigned to schema (the schema variable) with a
proper drf-yasg AutoSchema-compatible inspector or remove the dict so drf-yasg
uses serializer_class correctly; ensure GET responses documented reflect the
merged payload (MonitoringDeviceDetailSerializer + charts) and the CSV branch
documents/returns only chart data by updating the view’s schema implementation
to return the correct request/response schemas for get/post/csv.

---

ℹ️ Review info

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b740dea and 8cb6d0d.

📒 Files selected for processing (1)

• openwisp_monitoring/device/api/views.py

📜 Review details

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2026-02-21T18:44:28.852Z

Learnt from: dee077
Repo: openwisp/openwisp-monitoring PR: 738
File: openwisp_monitoring/device/api/views.py:263-281
Timestamp: 2026-02-21T18:44:28.852Z
Learning: In openwisp-monitoring, MonitoringIndoorCoordinatesList inherits organization scoping from the parent IndoorCoordinatesList (from openwisp-controller), which uses FilterByParentManaged mixin and filters by location_id in get_queryset(). The child class only overrides the queryset attribute to add monitoring-specific select_related fields; this pattern is safe as long as get_queryset() from the parent is not bypassed. During reviews, verify that MonitoringIndoorCoordinatesList continues to rely on the parent's get_queryset() and that any added select_related fields in the child do not alter the parent's filtering logic.

Applied to files:

• openwisp_monitoring/device/api/views.py

🧬 Code graph analysis (1)

openwisp_monitoring/device/api/views.py (1)

openwisp_monitoring/device/api/serializers.py (1)

• MonitoringDeviceDetailSerializer (109-110)

🔇 Additional comments (1)

openwisp_monitoring/device/api/views.py (1)

16-16: LGTM — import cleanup is correct.

Removing serializers from the import is accurate since serializers.Serializer is no longer referenced anywhere in the file.

[nemesifier]

@shakurah thanks for this! I think you're right. There's a suggestion from coderabbit which sounds valid see my comment below and let me know what you think.

[stktyagi]

try this -

[fix] Use self.serializers instead of hard Coded Serializer #716

Replaces direct use of MonitoringDeviceDetailSerializer with self.serializer_class to improve flexibility, allow overrides, and maintain consistent serializer usage across the view.

Fixes #716

thee are some of the valid tags
[feature/change/fix/chores/deps/ci]

[openwisp-companion]

CI Build Failed: Script Not Found

Hello @shakurah,
(Analysis for commit 4fac931)

• Build/Infrastructure/Other: The CI jobs are failing because the ./runtests script cannot be found. This indicates an issue with the build environment or the way the tests are being invoked.

Fix: Ensure that the ./runtests script is present and executable in the root directory of the repository before running the tests. If this is a CI-specific issue, the CI configuration might need adjustment to correctly check out or prepare the repository.

[openwisp-companion]

CI Failures: Black Formatting and Missing Script

Hello @shakurah,
(Analysis for commit d081547)

1. Code Style/QA: The Black check failed! Hint: did you forget to run openwisp-qa-format? error indicates a code formatting issue.

• Fix: Run the command openwisp-qa-format to automatically format the code.

2. Build/Infrastructure/Other: The Run ./runtests step failed with No such file or directory and exit code 127. This indicates that the runtests script is missing or not executable in the CI environment.

• Fix: Ensure the runtests script is present and executable in the CI environment. If it's a generated script, check the build process.

[openwisp-companion]

CI Failures: Black Formatting and Missing Test Script

Hello @shakurah,
(Analysis for commit cf916d7)

1. Code Style/QA: The Black check failed! error indicates that the code is not formatted according to the Black style guide.

• Fix: Run openwisp-qa-format to automatically format your code.

2. Build/Infrastructure/Other: The ./runtests: No such file or directory error indicates that the runtests script is missing or not executable in the CI environment. This is likely an infrastructure issue.

• Fix: This is likely an infrastructure issue. The CI has been restarted automatically. If the issue persists, please contact the CI maintainers.