Fix GetProfileByURN early return breaking URN transfers#97
Conversation
…p transfers - Removed early return in `GetProfileByURN` loop, allowing it to correctly traverse the full transaction history. - The state variable `profileState` now updates iteratively when valid transactions are found matching the ongoing `Creators` constraints. - Moved caching logic and final assignment of cursor fields (`Id`, `ProcessHeight`) to after the loop, ensuring it evaluates the full transaction log. - `profileState.Id` and `ProcessHeight` are now only appended safely if the URN properties loaded correctly and if the chain fetch completed properly. Co-authored-by: embiimob <[email protected]>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
…file tracking Co-authored-by: embiimob <[email protected]>
This commit fixes a bug in
PROState.GetProfileByURNwhere the function would incorrectly catch on an older, obsolete claim and fail to honor a transfer to a new creator address.The old logic immediately returned upon discovering the first transaction that successfully resolved the URN via
GetProfileByAddress(findObject). By changing the loop to iteratively updateprofileStateand removing the early return, the logic appropriately steps through the entire transaction chain for the URN. As transfers occur (original creator adds new address, new address assumes control), theContains(transaction.SignedBy)logic organically works across the loop sinceprofileStatereflects the new valid creator context.The caching update (
Root.AtomicWriteCacheFile) was subsequently shifted outside the loop to execute only once with the final, fully-resolved state.PR created automatically by Jules for task 15807905596006082608 started by @embiimob