bugfix integration with dpp/dlt #50
No reviewers
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Test Deployed
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: ereuse/devicehub-django#50
Loading…
Reference in a new issue
No description provided.
Delete branch "fix_build"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
we found a bug when building DPP after #48 (edit [2025-02-13 18:55], in fact, we were not testing DPP since long time ago, that includes the big refactor of #40 )
bug before
a1f10307e8
bug after
a1f10307e8
a1f10307e8
toccaa8834dc
fix bugto fix integration with dpp/dltfix integration with dpp/dltto bugfix integration with dpp/dltwe should remember that on dpp-dsg.ac.upc.edu we have a stable version, right now, what we call v2 (which took place at some point when we merged DPP branch into main
1ea400051c
)so, we are developing-stabilizing v3
I updated our dev server which serves as an example of what is the problem now
diffing v3 and v2 we can find errors of what should work
if you go to this address then we have a problem related to react searcher, src http://45.150.187.29/deepSearch?q=01e2927f1652896a1fd0c848391a36520fd76958bb61c63635a3610ab67d795a
if I inspect with browser dev tools, queries look the same
but I found something that is different, the algorithms 1-2 (ereuse24 and ereuse22 respectively) on the same version gives the same ID and that is not correct:
http://dpp-dsg.ac.upc.edu:8000/evidence/e7de22e2-f8a7-4051-b133-0a7a0e27611f
http://45.150.187.29:8000/evidence/ae913de1-e639-476a-ad9b-78eabbe4625b
so overall, the dpp integration is a good excuse to ensure different algorithm works
but, by the way, if we go to demo.ereuse.org, the ereuse22 is not shown when DPP is not enabled; hence, when DPP is enabled MAYBE we want to switch off ereuse24?
in session with @cayop we found that we are unable to reproduce the bug with new parse (inxi); and that old parse has
which correspond with the kind of error
is like the react part just want key-value structures, and don't want key-array
commit that fixed the issue:
73a582aeb3
we will work on the duplicated IDs in a different issue because does not have impact on the bugfix