Skip to content

Fix type assertion error messages in export discover#197

Merged
istein1 merged 2 commits intomainfrom
fix/type-assertion-error-messages
Apr 7, 2026
Merged

Fix type assertion error messages in export discover#197
istein1 merged 2 commits intomainfrom
fix/type-assertion-error-messages

Conversation

@istein1
Copy link
Copy Markdown
Member

@istein1 istein1 commented Mar 29, 2026

Summary

Fixed a bug where type assertion failure error messages displayed the nil pointer variable instead of the actual object type, making debugging difficult.

Changes:

  • cmd/export/discover.go:287 - In iterateItemsByGet(), changed error message to use object instead of u
  • cmd/export/discover.go:310 - In iterateItemsInList(), changed error message to use object instead of u

Before: When type assertion failed, error would show:

expected *unstructured.Unstructured but got <nil>

After: Error now correctly shows the actual type:

expected *unstructured.Unstructured but got *v1.ConfigMap

Impact

This is a low-severity bug that affects error message quality. When Kubernetes API returns an unexpected type during export operations, developers will now see helpful error messages indicating the actual type received, rather than confusing nil pointer messages.

Test plan

  • Code compiles successfully with go build ./cmd/export/...
  • Reviewer verifies the fix addresses the issue
  • No existing tests broken (error messages are cosmetic)

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Bug Fixes
    • Improved error handling when iterating items: functions now validate inputs before iterating and return a clear error if a required group/resource is missing.
    • Clarified error messages to show the actual runtime type encountered and the API resource name, removing confusing or incorrect type references and making it easier to identify which resource caused the error.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Mar 29, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: e5464092-0a4a-47db-a8b1-5ebfd9a4b390

📥 Commits

Reviewing files that changed from the base of the PR and between 4b1d0e1 and 9cfc0c0.

📒 Files selected for processing (1)
  • cmd/export/discover.go

📝 Walkthrough

Walkthrough

Both iteration helpers in cmd/export/discover.go now validate that the groupResource (g) parameter is non-nil and return a clear error if it is. Error messages and logs inside the list-item callback were updated to reference g.APIResource.Name and to report the runtime type of the object value (using object instead of the unused u).

Changes

Cohort / File(s) Summary
Iteration & logging fixes
cmd/export/discover.go
Added nil check for g in iterateItemsByGet and iterateItemsInList; updated callback logging to use g.APIResource.Name and changed type-reporting from %T of u to %T of object, plus corresponding error messages.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Suggested reviewers

  • kaovilai
  • aufi

Poem

🐰 I hopped through lines both short and neat,
Found a missing g and a phantom u to meet.
Now names are clear, and types show true,
Logs hum along with a tidier view.
🥕

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Fix type assertion error messages in export discover' directly and clearly reflects the main change: correcting type assertion error messages in the cmd/export/discover.go file by using the correct variable names.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

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

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/type-assertion-error-messages

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

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

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@cmd/export/discover.go`:
- Around line 286-287: The logger.Errorf calls in the two type-assertion failure
branches (the ones that currently pass g and object but use three format verbs)
have a format/argument mismatch and pass g where the object's runtime type is
expected; update both logger.Errorf invocations to use three verbs and pass the
arguments in the correct order so the object's type is logged first, then the
groupResource, then the object value (e.g. use a format like "expected
unstructured.Unstructured but got %T for groupResource %v and object: %#v" and
pass object, g, object to logger.Errorf in both branches).
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 843f1512-be48-4271-a9ed-42e21cfae730

📥 Commits

Reviewing files that changed from the base of the PR and between 188ea98 and bb6a29e.

📒 Files selected for processing (1)
  • cmd/export/discover.go

Comment thread cmd/export/discover.go Outdated
When type assertions failed, error messages displayed the nil pointer
variable instead of the actual object type, making debugging difficult.
Now error messages correctly show the actual type received.

Also fixed logger.Errorf format string mismatch where 3 format verbs
were used but only 2 arguments provided.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@istein1 istein1 force-pushed the fix/type-assertion-error-messages branch from bb6a29e to 4b1d0e1 Compare March 29, 2026 10:07
Copy link
Copy Markdown
Contributor

@stillalearner stillalearner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Copy link
Copy Markdown
Contributor

@aufi aufi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Just added a small comment, but no problem with merging.

Comment thread cmd/export/discover.go
// TODO: explore aggregating all the errors here instead of terminating the loop
logger.Errorf("expected unstructured.Unstructured but got %T for groupResource %s and object: %#v\n", g, object)
return fmt.Errorf("expected *unstructured.Unstructured but got %T", u)
logger.Errorf("expected unstructured.Unstructured but got %T for groupResource %s and object: %#v\n", object, g.APIResource.Name, object)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From this function point of view, g could be nil (after de-dereference, so g.APIResource.. could fail), but the rest of code doesn't look to make that possible, so just a note.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @aufi!
A g nil check was added above.

Add defensive nil checks in iterateItemsByGet and iterateItemsInList
to prevent potential nil pointer dereference of g.APIResource.

Addresses code review feedback on PR #197.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@istein1 istein1 merged commit 4d8d3d2 into main Apr 7, 2026
4 checks passed
@istein1 istein1 deleted the fix/type-assertion-error-messages branch April 7, 2026 14:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants