Replace string matching with JSON parsing in isRemoteWorkload - issue - 2941

[deepika1214]

Summary

Replaces string matching with proper JSON parsing in the isRemoteWorkload function to prevent false positives when detecting remote workloads.

Fixes

Closes #2941

Testing

All existing tests pass. New test validates the fix prevents false positives when JSON contains "remote_url" as part of a string value rather than as a field name.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 56.91%. Comparing base (aeab6bd) to head (159eb7b).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2968      +/-   ##
==========================================
+ Coverage   56.89%   56.91%   +0.02%     
==========================================
  Files         337      337              
  Lines       33617    33619       +2     
==========================================
+ Hits        19127    19135       +8     
+ Misses      12899    12895       -4     
+ Partials     1591     1589       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This PR fixes a bug in the isRemoteWorkload function where string matching on raw JSON could produce false positives. The fix replaces string matching with proper JSON parsing to accurately detect the presence and value of the remote_url field.

Key Changes

• Replaced io.ReadAll + strings.Contains with json.NewDecoder for proper JSON parsing in isRemoteWorkload
• Added whitespace trimming check to ensure empty or whitespace-only URLs are not considered remote
• Added comprehensive test cases covering edge cases including the false positive scenario

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
pkg/workloads/statuses/file_status.go	Refactored isRemoteWorkload to use JSON parsing instead of string matching; removed unnecessary io import
pkg/workloads/statuses/file_status_test.go	Added edge case tests for remote workload detection including false positive prevention

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The test reimplements the JSON parsing logic instead of testing the actual isRemoteWorkload function. This creates a disconnect where the test could pass even if the actual implementation has bugs.

Consider testing the actual isRemoteWorkload method by:

1. Creating a fileStatusManager with mocked runConfigStore
2. Setting up the mock to return different JSON configurations
3. Calling manager.isRemoteWorkload(ctx, "test-workload") and verifying the result

Example pattern used elsewhere in this file (see lines 103-111):

manager, _, mockRunConfigStore := newTestFileStatusManager(t, ctrl)
mockRunConfigStore.EXPECT().Exists(gomock.Any(), "test-workload").Return(true, nil)
mockReader := io.NopCloser(strings.NewReader(tt.configJSON))
mockRunConfigStore.EXPECT().GetReader(gomock.Any(), "test-workload").Return(mockReader, nil)
result, err := manager.isRemoteWorkload(ctx, "test-workload")

[jhrozek]

Good fix for the false positive bug! The JSON parsing approach is the right solution. One suggestion for test improvement below.

[jhrozek]

Test duplicates implementation logic instead of calling actual method

This test replicates the JSON parsing logic from isRemoteWorkload rather than calling the actual method. While this validates the parsing logic works, it doesn't provide regression protection if the method's behavior changes.

Suggested improvement:

1. Create a mock state.Store that returns a reader with the test JSON
2. Construct a fileStatusManager with the mock store
3. Call manager.isRemoteWorkload(ctx, workloadName) directly
4. Assert on the returned bool and error

This would ensure the test exercises the full code path including store interaction, reader handling, and the defer cleanup.

Note: This is a low-priority suggestion - the existing tests for GetWorkload do exercise isRemoteWorkload through integration paths, so there is some coverage.