jpie 3.8.3 → 3.9.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 5fee8d7ae2ce0016c8c6b1d0740cf9448d7b932c9d71fc0f74a553ae5bd15d17
-  data.tar.gz: 8d8151d6323ad4c3538abb0bb95f23347162d047006af7c9e7d03da638d4f955
+  metadata.gz: 4f3af561d7afa748d2a1095a6b3c83fe8ab42b12a6fb88655f67c023e72779ba
+  data.tar.gz: ea3c315885d7b2ae18f328bb6659c796e64e82b62b87ae479fd7d3faa0ef4f09
 SHA512:
-  metadata.gz: e8e86875e6b6c582640e9f7c03355a8dd271ecab3c1e96186a304f0927b28cccda7fb5009f013b37bf0bd5c778c280e29a03b765033c2e7fe1babba2bd24576a
-  data.tar.gz: 44feac1f5b20d4cb6c95f05773e06fefedb7cea9b254fb55a98af26a0b58f5dec60dae425f55bda8c10185f57099c7bd2450729a940c7a31eab8636acbdc1348
+  metadata.gz: edd52e432cec91efbd1487ebb8ad340fbe560879415ae6af400290b68e5c5bfa3db6f7afd967077bbf6a5509992329b412f865af88db19f80accadb8903f44e5
+  data.tar.gz: 1f9854c359c421410f19645ae03659137059e92f8bc88a1b52b3e79ac2906abe5747c859a46ed02a312ba8ab37e7f661fbce1c16e42a2a29e73e5446122889b1

data/.claude/skills/root-cause-analysis/SKILL.md

@@ -42,6 +42,12 @@ Gather facts before concluding. Prefer:
 
 Do not rely on assumptions. Evidence supports or refutes hypotheses.
 
+**Bind the error to the incident by identity, not by proximity.** An error in the same account, the same minute, the same job class, or the same feature area is NOT evidence that it caused the reported failure. Busy systems fire several unrelated errors in one window. Prove the link with a record identity that both sides share — the job arguments, the record GID, the message id, the request id. Sentry event details carry `job_arguments` and `extra`; open them and read the ids. If no shared id ties the error to the records the user named, you have a co-occurring error, not the cause.
+
+Search the failure's exact time window for EVERY error, not just the ones that match your first idea. Then pick the one whose arguments name the user's records. A narrow search that starts from a suspected culprit returns that culprit and hides the real one.
+
+**When the user's evidence contradicts your diagnosis, re-run the search.** Do not restate the theory in better words. Their report of what actually happened outranks your reading of the code. Treat the contradiction as a failed hypothesis and go back to evidence gathering.
+
 ## Methodology and verification
 
 - **5 Whys:** State the problem; ask "why?" repeatedly until you reach a cause you can fix. **Verify:** Would fixing this prevent the issue? If not, keep investigating.
@@ -55,6 +61,10 @@ Do not rely on assumptions. Evidence supports or refutes hypotheses.
 | "Let me try this quick fix" | You do not understand the cause |
 | "Maybe if I add a guard here" | Guessing, not debugging |
 | "Let me try a few things" | Random changes waste time |
+| "This error is in the same account and the same minute, so it is the one" | Co-occurrence is not causation; match a record id before you believe it |
+| "The related error is in the same job class / feature, close enough" | Same area is not same incident; open the event's arguments and match the ids |
+| "The user says it still fails, let me explain why my fix is right" | Their evidence beat your theory; re-run the search instead of defending |
+| "I found an error that fits my theory, stop searching" | Search the whole time window; a narrow search only confirms what you assumed |
 
 When you notice these, stop and run through problem definition, evidence, and one hypothesis at a time.
 

data/.cursor/agents/systematic-debugging.md

@@ -20,6 +20,7 @@ Do not recommend changing code just to pass specs, or changing specs just to mak
 - Review recent changes (git log, options, caller expectations).
 - Gather evidence (params, include, serializer path, input data).
 - Trace backwards from the failure to where correct behaviour diverges.
+- Bind each error you find to the reported incident by a shared record id (job arguments, record GID, message id, request id) — same account, same minute, or same feature is proximity, not proof. Search the whole failure window, not only what matches your first idea.
 
 ### Phase 2: Pattern analysis
 

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    jpie (3.8.3)
+    jpie (3.9.0)
       actionpack (~> 8.1, >= 8.1.0)
       pg_query (>= 4)
       prosopite (>= 1)

data/lib/json_api/serialization/concerns/relationship_processing.rb

@@ -61,26 +61,29 @@ module JSONAPI
 
       def process_to_many_relationship(attrs, association_name, param_name, data)
         ids = data.map { |r| extract_id(r) }
-        types = data.map { |r| extract_type(r) }
 
-        if types.any? && self.class.active_storage_blob_type?(types.first)
+        # An attachment must take the attachment path whether or not the client sends a
+        # `type`. JSON:API requires a resource identifier to carry `type` and `id`, so
+        # routing on the association itself keeps the spec-compliant payload working
+        # instead of falling through to the `<rel>_ids=` setter, which an attachment lacks.
+        if active_storage_attachment?(association_name)
           process_active_storage_attachment(attrs, association_name, ids, singular: false)
           return
         end
 
+        types = data.map { |r| extract_type(r) }
         validate_relationship_type(association_name, types.first) unless polymorphic_association?(association_name)
         attrs["#{param_name.singularize}_ids"] = ids
       end
 
       def process_to_one_relationship(attrs, association_name, param_name, data)
         id = extract_id(data)
-        type = extract_type(data)
 
-        if self.class.active_storage_blob_type?(type)
+        if active_storage_attachment?(association_name)
           return process_active_storage_attachment(attrs, association_name, id, singular: true)
         end
 
-        process_regular_to_one_relationship(attrs, association_name, param_name, id, type)
+        process_regular_to_one_relationship(attrs, association_name, param_name, id, extract_type(data))
       end
 
       def process_regular_to_one_relationship(attrs, association_name, param_name, id, type)

data/lib/json_api/serialization/concerns/relationships_serialization.rb

@@ -45,14 +45,19 @@ module JSONAPI
         relationships[association_name] = result
       end
 
+      # Linkage carries a type and an id, so reading the association directly
+      # leaks the identity of a record the related endpoint denies — the same
+      # bypass the `included` section closes, with a narrower payload. Both
+      # sections resolve through one authorized read, so they always describe
+      # the same set, and the request-scoped filter cache means the second
+      # reader vets nothing the first already vetted.
       def serialize_relationship_data(association)
-        related = record.public_send(association.name)
+        related = get_association_records(record, association.name)
 
-        if association.collection?
-          serialize_collection_relationship(related, association)
-        elsif related
-          serialize_single_relationship(related, association)
-        end
+        return serialize_collection_relationship(related, association) if association.collection?
+
+        first = related.first
+        serialize_single_relationship(first, association) if first
       end
 
       def serialize_collection_relationship(related, association)

data/lib/json_api/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module JSONAPI
-  VERSION = "3.8.3"
+  VERSION = "3.9.0"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: jpie
 version: !ruby/object:Gem::Version
-  version: 3.8.3
+  version: 3.9.0
 platform: ruby
 authors:
 - Emil Kampp
@@ -222,7 +222,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.6.9
+rubygems_version: 3.7.2
 specification_version: 4
 summary: JSON:API compliant Rails gem for producing and consuming JSON:API resources
 test_files: []