Fix duplicate collection id #2508

ipdae · 2024-04-03T12:14:25Z

resolve 콜렉션 스탯 적용때 중복값 제거하기 #2501
distinct collection ids when serialize & deserialize collection state

pull-request-quantifier-deprecated · 2024-04-03T12:25:28Z

This PR has 31 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +18 -13
Percentile : 12.4%

Total files changed: 7

Change summary by file extension:
.cs : +18 -13

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

eugene-doobu · 2024-04-04T02:35:23Z

Lib9c/Model/State/CollectionState.cs

@@ -22,12 +25,25 @@ public CollectionState(List serialized)
            {
                Ids.Add((Integer)value);
            }
+
+            Ids = Ids.Distinct().ToList();


Ids를 Set과 같은 형태로 관리해도 되지 않을까요?

sonohoshi · 2024-04-04T02:59:34Z

Lib9c/Model/State/CollectionState.cs

        }

        public CollectionState(IValue bencoded) : this((List)bencoded)
        {
        }

-        public IValue Bencoded => List.Empty.Add(new List(Ids));
+        public IValue Bencoded => List.Empty.Add(new List(Ids.Distinct()));


이거 Distinct 한 뒤에 List 내의 순서 같은게 달라서 상태 불일치가 생길 가능성은 없을까요?

직렬화된 상태가 순서에 영향을 안받는것으로 알고 있습니다. 정렬이 필요할까요? @planetarium/libplanet

아 그럼 이 내용은 엔진팀에서 확인&답변 부탁드립니다🙇‍♂️

Distinct 자체가 정렬을 담보하지는 않지만, List<T>.Distinct 자체가 원래 있던 순서를 유지하는 동작을 하고 있으므로 상관은 없을 겁니다.

다만 @sonohoshi 님이 말씀하신 대로 그렇게 좋은 프랙티스는 아니라고 생각하고, Active Migration 이후에 코드를 지우는 일은 필요 해 보이긴 합니다.

pull-request-quantifier-deprecated · 2024-04-04T06:27:06Z

This PR has 37 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +19 -18
Percentile : 14.8%

Total files changed: 8

Change summary by file extension:
.cs : +19 -18

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

ipdae · 2024-04-04T06:27:30Z

SortedSet을 사용하도록 변경했습니다. 다시 한번 리뷰 부탁드립니다. @sonohoshi @eugene-doobu

.Lib9c.Tests/Model/State/CollectionStateTest.cs

pull-request-quantifier-deprecated · 2024-04-04T06:34:12Z

This PR has 37 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +19 -18
Percentile : 14.8%

Total files changed: 8

Change summary by file extension:
.cs : +19 -18

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-04-04T06:35:31Z

This PR has 40 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +21 -19
Percentile : 16%

Total files changed: 8

Change summary by file extension:
.cs : +21 -19

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-04-04T07:01:45Z

This PR has 40 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +21 -19
Percentile : 16%

Total files changed: 8

Change summary by file extension:
.cs : +21 -19

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

ipdae added 2 commits April 3, 2024 20:35

Refactor collection state modifiers

8dda29c

Fix duplicate activated collection ids

307023c

ipdae added this to the v170.0.0 milestone Apr 3, 2024

ipdae requested a review from a team April 3, 2024 12:14

ipdae self-assigned this Apr 3, 2024

pull-request-quantifier-deprecated bot added the Extra Small label Apr 3, 2024

ipdae changed the title ~~Bugfix/issue 2501~~ Fix duplicate collection id Apr 4, 2024

eugene-doobu reviewed Apr 4, 2024

View reviewed changes

sonohoshi reviewed Apr 4, 2024

View reviewed changes

Use SortedSet instead of list

3fc752b

ipdae requested review from sonohoshi and eugene-doobu April 4, 2024 06:27

sonohoshi reviewed Apr 4, 2024

View reviewed changes

.Lib9c.Tests/Model/State/CollectionStateTest.cs Outdated Show resolved Hide resolved

Fix test

34ef59f

ipdae force-pushed the bugfix/issue-2501 branch from 9d8115a to 34ef59f Compare April 4, 2024 06:35

sonohoshi approved these changes Apr 4, 2024

View reviewed changes

ipdae enabled auto-merge April 4, 2024 07:01

Merge branch 'development' into bugfix/issue-2501

8497a80

ipdae merged commit 7a3d932 into development Apr 4, 2024
12 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix duplicate collection id #2508

Fix duplicate collection id #2508

ipdae commented Apr 3, 2024

pull-request-quantifier-deprecated bot commented Apr 3, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

eugene-doobu Apr 4, 2024

sonohoshi Apr 4, 2024 •

edited

Loading

ipdae Apr 4, 2024

sonohoshi Apr 4, 2024

riemannulus Apr 4, 2024

pull-request-quantifier-deprecated bot commented Apr 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

ipdae commented Apr 4, 2024

pull-request-quantifier-deprecated bot commented Apr 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Apr 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Apr 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Fix duplicate collection id #2508

Fix duplicate collection id #2508

Conversation

ipdae commented Apr 3, 2024

pull-request-quantifier-deprecated bot commented Apr 3, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

eugene-doobu Apr 4, 2024

Choose a reason for hiding this comment

sonohoshi Apr 4, 2024 • edited Loading

Choose a reason for hiding this comment

ipdae Apr 4, 2024

Choose a reason for hiding this comment

sonohoshi Apr 4, 2024

Choose a reason for hiding this comment

riemannulus Apr 4, 2024

Choose a reason for hiding this comment

pull-request-quantifier-deprecated bot commented Apr 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

ipdae commented Apr 4, 2024

pull-request-quantifier-deprecated bot commented Apr 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Apr 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Apr 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

sonohoshi Apr 4, 2024 •

edited

Loading