[CDX-415] Add related searches and related browse pages

[TarekAlQaddy]

https://linear.app/constructor/issue/CDX-415/java-sdk-add-support-for-related-searches-and-related-browse-pages-in

[Copilot]

Pull request overview

Adds Java SDK support for related searches and related browse pages returned in search responses (CDX-415), including model types, deserialization wiring, and tests/fixtures.

Changes:

• Extend SearchResponseInner to deserialize related_searches and related_browse_pages.
• Add new model types: RelatedSearch and RelatedBrowsePage.
• Update search response fixture and add unit tests validating the new fields.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
constructorio-client/src/test/resources/response.search.item.json	Adds related_searches and related_browse_pages to the search response fixture JSON.
constructorio-client/src/test/java/io/constructor/client/SearchResponseTest.java	Adds tests asserting the new response fields are deserialized.
constructorio-client/src/main/java/io/constructor/client/models/SearchResponseInner.java	Adds Gson-mapped fields + getters/setters for related searches and browse pages.
constructorio-client/src/main/java/io/constructor/client/models/RelatedSearch.java	New model for related_searches entries.
constructorio-client/src/main/java/io/constructor/client/models/RelatedBrowsePage.java	New model for related_browse_pages entries.

---

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

[constructor-claude-bedrock]

Code Review Summary

This PR adds support for related searches and related browse pages in the search response (CDX-415). It introduces two new model classes (RelatedSearch, RelatedBrowsePage), extends SearchResponseInner with the new fields, adds tests, and updates the test fixture JSON. It also corrects several existing test assertions to match the actual HTTP error codes/messages returned by the API. Overall the implementation is clean and follows established patterns. A few items worth addressing are noted below.

---

Detailed Feedback

[File: RelatedBrowsePage.java - General] The new model is well-structured and consistent with the rest of the codebase. The class-level Javadoc comment matches the pattern used in other models. No issues.

[File: RelatedSearch.java - General] Minimal and correct. Good.

[File: SearchResponseInner.java Lines: L53-L84] The new getter/setter methods use multi-line Javadoc blocks, but all existing methods in this file (and across the entire models package) use single-line getters/setters without Javadoc comments. This creates a style inconsistency within the same class:

Existing style in this file (no Javadoc, single-line):

public List<Feature> getFeatures() { return features; }
public void setFeatures(List<Feature> features) { this.features = features; }

New code (multi-line with Javadoc) - inconsistent with above:

/**
 * @return list of related searches
 */
public List<RelatedSearch> getRelatedSearches() {
    return relatedSearches;
}

Suggest matching the concise single-line style already present in this file to maintain consistency.

[File: SearchResponseTest.java Lines: L339-L399] The new test assertions use assertEquals(message, actual, expected) - the argument order is reversed relative to JUnit 4 convention, which is assertEquals(String message, Object expected, Object actual). This means expected and actual are swapped in failure messages, making them misleading when a test fails:

// Current (reversed - actual comes before expected):
assertEquals(
    "search result [related searches] exists",
    response.getResponse().getRelatedSearches().size(),  // actual
    2);                                                   // expected

// Correct JUnit 4 convention:
assertEquals(
    "search result [related searches] exists",
    2,                                                    // expected
    response.getResponse().getRelatedSearches().size()); // actual

Note: this reversed-order pattern exists throughout the pre-existing tests in this file - but worth correcting going forward.

[File: SearchResponseTest.java Lines: L370-L399] In createSearchResponseShouldReturnAResultWithRelatedBrowsePages, the assertion message for getFilterName() on the second browse page entry is identical to the first: "search result related browse page [filter name] exists". When either fails, it will be hard to tell which item is the culprit. Consider adding an index to the message (e.g. "[0] filter_name" vs "[1] filter_name").

[Files: ConstructorIOTaskTest.java & ConstructorIOTasksTest.java] The corrections from a hardcoded auth error message to StringContains.containsString("[HTTP 401] Unauthorized"), and from [HTTP 401] to [HTTP 400] for invalid API key errors, are appropriate. Using StringContains is more resilient to minor API message wording changes. Good fixes.

[General - Missing null/absent field tests] Neither getRelatedSearches() nor getRelatedBrowsePages() is tested for the case where these fields are absent from the API response (i.e., returns null). Both fields are optional and callers could hit a NullPointerException calling .size() without a null check. Consider adding a test against a fixture that lacks these fields to confirm they deserialize to null gracefully - this documents the contract and guards against regressions.

[General - Shared fixture response.search.item.json] Adding related_searches and related_browse_pages to the shared fixture is fine - a review of the other tests using this fixture confirms none assert the absence of these fields.

---

Conclusion

This is a clean, well-scoped addition that correctly follows the existing model and test patterns. The main actionable items are:

1. Align the Javadoc/method style in SearchResponseInner.java with the existing single-line getter/setter pattern used in the same class.
2. Add a null-safety test for responses that omit related_searches/related_browse_pages, to document the null-return contract and protect callers.
3. (Minor) Disambiguate the repeated assertion messages in the browse page test for clearer failure output.

[esezen]

LGTM!