Inconsistencies in Event time into the round

Anyone else experiencing this issue?  I'm currently comparing some results against Akiver's CSGO Demo Manager and find that the event times (during a round) are significantly different.  From my knowledge so far, akiver's event time is (Event time in Tick - Freeze Time end Tick)/Server Tick Rate (128).  I am doing this as well on this end but getting times that are a lot lower in general.  Anyone else encounter this issue?
Example Code:
    def on_player_death(event, msg):
        event_seconds = (demo.current_tick - round_start_tick)/128 # I've verified using demo header that its 128 server tick rate
        print(event_seconds)

    def on_round_freeze_end(event, msg):
        round_start_tick = demo.current_tick

    demo.add_callback('round_freeze_end', on_round_freeze_end)
    demo.add_callback('player_death', on_player_death)

Output on my end:
38.3125
45.96875
47.9375
...

Corresponding output from csgo demo manager:
0:53
1:00
1:02
...

Demo: https://drive.google.com/file/d/1weNEgl6K8uwAF2rATeUDXMUJPpbZfhos/view?usp=sharing

You need to add global round_start_tick to on_round_freeze_end. Right now it's just declaring a local variable of the same name in that function. Here is the full output of my run of that demo (I've rounded the time in seconds): http://paste.openstack.org/show/731897/. Does that match up with the akiver results?

unfortunately it doesnt.  i forgot to say i  simplified my code down to the core issue.  round_start_tick was a class variable so that issue wouldnt occur.
the output you get compared to akivers is different and is the same as mine (line 28 to 35)

It's never that easy :)
Is there any way you can dump the actual ticks that the events occur from csgo-demos-manager? It looks like the events are occurring in the correct order and when I take the difference in ticks between the round_start event and the round_freeze_end I get roughly 1920. 1920 ticks is 15 seconds which is the default value of mp_freezetime.


Update which-branch-should-i-use.md

Changed to https://docs.microsoft.com/en-us/system-center/index, and updated date

@ramseygr    This is a duplicate PR for the same change. The other was already approved. Closing this one.


Implement a new API schema to match the Next.js file-system based router, with proper URL segments and query params.

Request:
Replace the past schema with lots of query parameters to a new system with URL segments and query params just for necessary values.
Examples:
Old URL:
https://apis.impactu.colav.co/app/search?data=affiliations&type=institution&max=10&page=1&sort=citations
"data" and "type" must be remove as query params.
New URL:
https://apis.impactu.colav.co/app/search/affiliations/institution?max=10&page=1&sort=citations
Segments for Search Results:

Affiliations:
/app/search/affiliations/institution
/app/search/affiliations/group
/app/search/affiliations/faculty
/app/search/affiliations/department

Works:
/app/search/work

Authors:
/app/search/person

Query Params for Search Results (entities and authors):
sort=citations -> desc order by citations_count.
sort=products -> desc order by products_count.
max=10 -> number of items per page.
page=1 -> page number.
filter_by_*=? -> to discuss...
keywords=example -> Word to search for.
Query Params for Search Results (works):
sort=citations -> desc order by citations_count.
sort=year -> desc order by year_published.
max=10 -> number of items per page.
page=1 -> page number.
filter_by_*=? -> to discuss...
keywords=example -> Word to search for.
URL for profiles (Segments + Query Params):
What was previously delivered in section=info must now be delivered by consulting the URL up to the /[ID] segment
Old endpoint:
{backend}/app/affiliation?type=institution&id=65c6a5f0917a3b88e2c252ea&section=info
New endpoint:
{backend}/app/affiliation/institution/65c6a5f0917a3b88e2c252ea

Works:
/app/work/[ID]

Authors:
/app/person/[ID]/research/products

Entities:
/app/affiliation/institution/[ID]/research/products
/app/affiliation/group/[ID]/research/products
/app/affiliation/faculty/[ID]/research/products
/app/affiliation/department/[ID]/research/products

Works:
/app/work/[ID] + ?section=info

Authors:
/app/person/[ID] + ?section=research&tab=products

Entities:
/app/affiliation/institution/[ID] + ?section=research&tab=products
/app/affiliation/group/[ID] + ?section=research&tab=products
/app/affiliation/faculty/[ID] + ?section=research&tab=products
/app/affiliation/department/[ID] + ?section=research&tab=products

[ID] ->is a Dynamic Segment -> "64190ec91654767daee7a434" -> Mongo unique identifier.
Profile's internal requests (not in browser's URL - entities and authors):
/app/affiliation/{Entity or Author}/[ID] -> Entity basic info + available filters.
/app/affiliation/{Entity or Author}/[ID]/research/products?page=1&max=10 -> Products list.
/app/affiliation/{Entity or Author}/[ID]/research/products?plot=* -> * A unique name for each plot, see H.U. & C.A.

The section and tab params are now path params
d87756c9d4714d06a5de887f410cc5f8bb60f52e


Header spacing off on Android device

The header spacing is inconsistent on my android device. It looks fine when running in the browser, but it seems to be off only on the device.

Posted on SO as well...http://stackoverflow.com/questions/34235774/ionic-slide-tabs-header-spacing-is-off


fix(login): centered login on larger viewports

fixes https://github.com/patternfly/patternfly-next/issues/2729

Preview: https://patternfly-next-pr-2754.surge.sh

:tada: This PR is included in version 2.66.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Resource clones can't be used at the same time

Read this comment then consider this code:
const serviceBase = new Resource("/path/to/your/service");
const serviceTypes = ["a", "b", "c", "d"];
serviceTypes.forEach(t => {
  const endpoint = serviceBase.clone();
  const fd = new FormData({serviceType: t});
  endpoint.post(fd).then(
    resp => console.log(t + " responded.", resp),
    err => console.log(t + " failed.", err);
  );
});

Currently, this will spew a bunch of errors on the console, "resource is already being fetched".  It violates the expectation that in
const r1 = new Resource("/path");
const r2 = new Resource("/path");
const r3 = r1.clone();

all three resources could be used interchangeably.  This is not true, because r1 and r2 can run at the same time, but r1 and r3 cannot.
I'm not totally clear on what the comment means about "breaking the request scheduler", so I'm sure there are implications to consider, but on the face of it, I think clone() needs to always make a new Request.  If it isn't going to make a new one, the docs need to carefully explain the implications of clone(), and describe how a clone is different from a first-class Resource.
In the short term, getDerivedResource({}) (note the empty object as sole argument) is basically a drop-in replacement for how I expected clone() to work.

The reason is that clone creates a shallow copy, so the internal Request object is shared. The Request object is managed by one of the underlying systems within Cesium (eg Terrain, Imagery, etc), so making a copy would break a lot of stuff.
The clone method was there so that we can make a copy of a resource passed into other Cesium classes as an argument, preventing the user from changing resource properties without us knowing. clone should probably be marked private as this behavior doesn't make sense if used outside the Cesium code. Another alternative is fix clone to make a deep copy and add a private method with the current functionality for internal use.

Either of those options sounds good -- I know it's a new class and the API is probably not set in stone just yet.  I mentioned a few similar (small) things in #6205 .  I don't expect it any time soon but maybe an example (blog post or Sandcastle) showing a few use cases for Resource would help clarify?

Fixed with #6211


prevent invalid workflow hops, preliminary fix. #4310

Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Run mvn clean install apache-rat:check to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[x] If you have a group of commits related to the same change, please squash your commits into one and force push your branch using git rebase -i.
[x] Mention the appropriate issue in your description (for example: addresses #123), if applicable.

To make clear that you license your contribution under the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

[x] I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004
[ ] In any other case, please file an Apache Individual Contributor License Agreement.

I get 2 pop-ups when making a loop.


Equations-stuff

Added inspect and eq: notation for Equations
Extracted NatExtras from the dev repo

Ah, just want to flag up one issue here. Once we merge this PR, the Papillon build will cease to work.


#203 resurrected acceptance/mixed_driver_management tests

What
Adopt tests_from_past/acceptance/mixed_driver_management to selene v2.
Why
In case of porting tests to v2 selene #203.
ToDo

[x] Adopt tests_from_past/acceptance/mixed_driver_management to selene v2.
[ ] Fix bugs/tests.

Definition of done

[ ] tests passed
[ ] review passed

Help wanted.
Tests are fail on selene v2.0.34a.

Help wanted.
Tests are fail on selene v2.0.34a.

Codecov Report

Merging #242 (fc85212) into master (183ae5d) will decrease coverage by 4.87%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #242      +/-   ##
==========================================
- Coverage   61.43%   56.55%   -4.88%
==========================================
  Files          32       32
  Lines        1846     1846
  Branches      116      116
==========================================
- Hits         1134     1044      -90
- Misses        682      772      +90
  Partials       30       30

Flag
Coverage Δ

unittests
56.55% <ø> (-4.88%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

selene/support/webdriver.py
45.83% <0.00%> (-25.01%)
:arrow_down:

selene/support/shared/jquery_style.py
85.71% <0.00%> (-14.29%)
:arrow_down:

selene/core/entity.py
51.76% <0.00%> (-7.61%)
:arrow_down:

selene/support/shared/config.py
71.25% <0.00%> (-7.50%)
:arrow_down:

selene/support/by.py
62.06% <0.00%> (-6.90%)
:arrow_down:

selene/support/conditions/have.py
58.90% <0.00%> (-6.85%)
:arrow_down:

selene/core/match.py
51.09% <0.00%> (-6.57%)
:arrow_down:

selene/common/helpers.py
79.16% <0.00%> (-4.17%)
:arrow_down:

selene/core/wait.py
83.33% <0.00%> (-3.71%)
:arrow_down:

selene/common/predicate.py
75.00% <0.00%> (-3.13%)
:arrow_down:

... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 183ae5d...fc85212. Read the comment docs.

Codecov Report

Merging #242 (fc85212) into master (183ae5d) will decrease coverage by 4.87%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #242      +/-   ##
==========================================
- Coverage   61.43%   56.55%   -4.88%
==========================================
  Files          32       32
  Lines        1846     1846
  Branches      116      116
==========================================
- Hits         1134     1044      -90
- Misses        682      772      +90
  Partials       30       30

Flag
Coverage Δ

unittests
56.55% <ø> (-4.88%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

selene/support/webdriver.py
45.83% <0.00%> (-25.01%)
:arrow_down:

selene/support/shared/jquery_style.py
85.71% <0.00%> (-14.29%)
:arrow_down:

selene/core/entity.py
51.76% <0.00%> (-7.61%)
:arrow_down:

selene/support/shared/config.py
71.25% <0.00%> (-7.50%)
:arrow_down:

selene/support/by.py
62.06% <0.00%> (-6.90%)
:arrow_down:

selene/support/conditions/have.py
58.90% <0.00%> (-6.85%)
:arrow_down:

selene/core/match.py
51.09% <0.00%> (-6.57%)
:arrow_down:

selene/common/helpers.py
79.16% <0.00%> (-4.17%)
:arrow_down:

selene/core/wait.py
83.33% <0.00%> (-3.71%)
:arrow_down:

selene/common/predicate.py
75.00% <0.00%> (-3.13%)
:arrow_down:

... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 183ae5d...fc85212. Read the comment docs.

@yashaka I didn't notice you have fixed shared browser reinitialization because there was no push commit to this PR and no re-test and recount code-cov report. It came already as merged to master and i worried that we have broken tests, until i went to commit history and saw your commit msg and commit and that after your last commit tests have been passed.

@yashaka I didn't notice you have fixed shared browser reinitialization because there was no push commit to this PR and no re-test and recount code-cov report.


Cannot compile after rebasing

Describe the bug
With latest git
commit c2be1612ee2294dd88a2b17b66cae48945643f6e (upstream/master)
Merge: 39ae3559f c3a4f977c
Author: Matt Liberty<EMAIL_ADDRESS>Date:   Mon Jul 29 23:22:54 2024 -0700
Merge pull request #5473 from Pinata-Consulting/python-black

python: ran black .

home/costa/OpenROAD/src/gui/src/staGuiInterface.cpp: In member function ‘void gui::STAGuiInterface::updatePathGroups()’:
/home/costa/OpenROAD/src/gui/src/staGuiInterface.cpp:934:11: error: ‘class sta::Search’ has no member named ‘updatePathGroups’; did you mean ‘deletePathGroups’?
934 |   search->updatePathGroups(1,         /* group count */
|           ^~~~~~~~~~~~~~~~
|           deletePathGroups
make[2]: *** [src/gui/CMakeFiles/gui.dir/build.make:414: src/gui/CMakeFiles/gui.dir/src/staGuiInterface.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:5819: src/gui/CMakeFiles/gui.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
Expected Behavior
No error
Environment
Latest git

To Reproduce
Standard build
Relevant log output
No response
Screenshots
No response
Additional Context
No response

I think the submodules were not updated. Testing.

Confirming. Compiles now.


TTI(Text 2 Image) inference using stable-diffusion.cpp doesn't work properly on Android phone

The Project stable-diffusion.cpp is excellent and thanks for your amazing stable-diffusion.cpp. I want to utilize the stable-diffusion.cpp as TTI(Text 2 Image) engine in my learning project.
TTI(Text 2 Image) inference using stable-diffusion.cpp doesn't work properly on Android phone  currently
https://github.com/zhouwg/kantv/blob/master/core/ggml/stablediffusioncpp/model.cpp#L773
https://github.com/zhouwg/kantv/blob/master/core/ggml/stablediffusioncpp/stable-diffusion.cpp#L189
I found that GGML's internal / GGML API changes quickly/frequently. could you help to merge upstream GGML source code to stable-diffusion.cpp?
thanks for your time and thanks so much.

The repo uses ggml @ 57869ad, you should not use the latest version of ggml

The repo uses ggml @ 57869ad, you should not use the latest version of ggml

thanks for you comment.
I see. but the whisper.cpp and llama.cpp couldn't works with ggml @ 57869ad


RP2040 + ICS-43432 issue

Hi @miketeachman,
As promised, here I am with my test results.
I'm using a ICS-43432 I2S MEMS mic. It outputs 24-bit data, little endian, every 64 clock cycles.
Here is its data sheet:
https://invensense.tdk.com/wp-content/uploads/2015/02/ICS-43432_DS.pdf
My test program:
from machine import I2S, Pin

buf = bytearray(10000)

i2s = I2S(0, sck=Pin(6), ws=Pin(7), sd=Pin(8), mode=I2S.RX, bits=32, format=I2S.MONO, rate=44100, ibuf=40000)

while True:
    ret = i2s.readinto(buf)
    for i in range(0, 20, 4):
        print(buf[i])
        print(buf[i + 1])
        print(buf[i + 2])
        print(buf[i + 3])
        print("------------")

Running on:
MicroPython v1.18 on 2022-01-17; Raspberry Pi Pico with RP2040

Some output:
0
102
2
0
------------
192
67
0
0
------------
192
71
2
0
------------
0
16
250
255
------------
192
79
250
255
------------
0
84
254
255
------------
192
93
248
255
------------
0
68
254
255
------------
192
57
254
255
------------
192
99
251
255
------------
0
202
0
0
------------
0
208
250
255
------------
0
60
253
255
------------
192
183
4
0
------------
192
21
255
255
------------
192
13
2
0
------------
192
241
0
0
------------

What I noticed is that the first byte is always 0 or 192.
I've tried the same mic with a Raspberry Pi and some C code and that is not the case.
Can you think of anything causing this?
Thanks!

This is the gold standard on how to present an issue !
I have a theory on the issue:   The SD line is staying high for a couple of bit times after the line has gone tri-state, after the 24th bit has been output, but only in the case where the 24th bit is high.  For example, you see a 192 (0xC0), when bit 24 is high.  Look at the bit immediately before a 192 result...it is always 1.  When the last bit of the 3rd byte is 0, then the 4th byte is always 0x00.
What's going on?   There is always a small capacitance between SD and ground.  When the mic tri-states the line (after the 3rd byte), and the line is high, there needs to be some resistance to ground to bring the line back to low, to discharge this capacitance.  In your hardware setup with the Pico, the SD line is going low too slowly, hence the two high bits times (0xC00).  When the line is already low, there is no capacitance to discharge, hence you see the expected value of the 4th byte (0x00).
How to fix:  It can be fixed in hardware.
From the mic datasheet:
The SD trace should have a pulldown resistor to discharge the line during the time that all microphones on the bus have tri-stated their outputs. A 100 kΩ resistor is sufficient for this, as shown in Figure 10. If the SD line needs to be discharged faster than a 100 kΩ resistor can, a smaller resistor, such as 10 kΩ, can be used.
To test the theory -- add a smaller value pull-down resistor, between the SD signal and ground, e.g.  47k ohm, or 10k ohm.  See if the 0xC0 value changes to 0x00.  It might change to 0x80 which is moving in the right direction, but still indicates that a smaller resistor is needed to discharge the capacitance on the SD line.
With the Raspberry Pi setup there may already be a resistor in place that discharges this capacitance at a faster rate.

I have a theory on the issue: The SD line is staying high for a couple of bit times after the line has gone tri-state, after the 24th bit has been output, but only in the case where the 24th bit is high. For example, you see a 192 (0xC0), when bit 24 is high. Look at the bit immediately before a 192 result...it is always 1.

Maybe I'm misunderstanding you, but I don't see what you are saying:
0        // byte 1 (buf[i])
102      // byte 2 (buf[i + 1])
2        // byte 3 (buf[i + 2])
0        // byte 4 (buf[i + 3])
------------
192
67
0
0
------------
192
71
2
0

Here the 192's come after zeros on the 3rd and 4th bytes.

When the last bit of the 3rd byte is 0, then the 4th byte is always 0x00.

It looks to me that the 4th byte is always the continuation of the sign, i.e. if the 24th bit (last bit of the 3rd byte) is 1, then the 4th byte if 0xff, 0x00 otherwise.
Am I missing something?
Thanks!

I see the confusion -- in my explanation I am using the byte ordering as output on the physical I2S SD line, as shown in figure 11 of the ICS-43432 datasheet.  But it doesn't get translated to the MicroPython array in that same order.  It's reversed.
Here is a translation from the sample bytes that come from the actual device to the MicroPython buf[] array.
I2S SD line                                                                   MicroPython buf[]
=======                                                                       ============
1st byte (Most significant byte, first to be transmitted from the mic)        buf[i+3]
2nd byte                                                                      buf[i+2]
3rd byte (Least significant byte of data transmitted from the mic)            buf[i+1]
4th byte (mic is in tri-state for this data, needs the pull-down to read 0)   buf[i]

It might help to look at one of your samples,
looking at the bits, as the order they appear on the physical I2S SD line:
0  <-- most significant data byte of data transmitted from the mic
0
67 (0x43)  <-- least significant byte of data transmitted from the mic
192 (0xC0)  <-- mic is in tri-state
It appears on the SD line in this order, MS bit --> LS bit
0x00     0x00     0x43     0xC0
00000000 00000000 01000011 11000000
                         ^
                         this bit being high causes the following two bits to be high
                         (due to the lack of adequate pull-down resistance)

I think this is the best I can explain it.

And this must be the gold standard of explanation!
Well, I think I found the real issue here: it got stuck in my head the idea that the ICS-43432 would transmit bytes with little endian format (i.e. LSB first), I even wrote it in the initial issue description! 🤦
I guess the idea came from the format used by ALSA to return data in my RPi code, and then the idea got reinforced by the fact that I saw non-zero data on the last byte (the famous 192), plus it made sense to me to see a sign continuation (unpulled tri-state) in what I assumed was the last transmitted byte which, in fact, was the first...
@miketeachman sorry for wasting your time and thank you very much for your patience, much appreciated!
Case closed!

Hey, great !   I'm glad this issue didn't turn into a difficult debugging exercise.   Understanding the data coming from I2S is not trivial.  The byte ordering seems backwards from what is expected.  Good luck with your projects.

Hi @miketeachman,
This might have been another reason that lead to my wrong interpretation of the bytes ordering:
https://github.com/micropython/micropython/blob/master/ports/rp2/machine_i2s.c#L65
Maybe it can be clarified?
Thanks!

I'm not sure how to make it better.  The appbuf[] is in little-endian ordering and the comment indicates little-endian ordering.   e.g.  appbuf[i+3] = most-significant byte, appbuf[i] = least-significant byte.
Which is the same as shown in the "Endian example" figure in wikipedia.
https://en.wikipedia.org/wiki/Endianness

Well... you are right, it is indeed clear enough. While this issue is resolved, it looks like the one in my head isn't :)

No worries.  I can never remember endianness.  When I commented the code I had to consult wikipedia to make sure the comment was correct.


Party Mode fails with a large song library

Might be better to use the PartyMode option with Player.Open()

Can you elaborate?

Sorry, didn't mean to leave this with so little info -- was in the middle of other things when I created the Issue (just so I wouldn't forget about it).  I'll post back in a bit with more info.

Cool

I see what you mean now. I have this fixed locally and will merge it with the new flask-ask branch.


Added more (tech) news outlets

I have added more (tech) news outlets - Kaspersky Blog, Bleeping Computer, Dark Reading, The Hacker News and the Avast blog.

Uh so now what?

Hey @CattopyTheWeb! Thank you for your contribution. We appreciate you adding new sources, but we don't require them since:

We already have enough.
We are now focussing on the blogging system.
We would have to overhaul our entire register section which we are not willing to since we have already closed that page, for now at the very least.

Looking forward to more contributions from you! Cheers 🍻🍻

We will keep this PR in mind and reopen it if we change our mind

Hey one of our news sources failed us so we are back and reopening this PR

I removed most of the sources because of:

Avast and Kaspersky are antivirus companies
Dark Reader news isn't tech related
Bleeping computer and Hacker news are okay, but we have better options


added safe deallocation for KeysClause with keys_clause_free function

it seems like your PR has been generated with chatgpt and does not make any sense so I'll go ahead and close it 👍


Make amounts of heads configurable

Good afternoon, is it possible to add heads from the item to the config? It seems to me that 8 is a lot for one block

ty <3

Added in 27c6e2711103203ed2ed5f96e390db71e091d966


[AVM Module Issue]: Feature Request-LAW-Need capability to add onboardingStates extension resource

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Issue Type?
Feature Request
Module Name
avm/res/operational-insights/workspace
(Optional) Module Version
No response
Description
Can we have the capability to add Microsoft.SecuirtyInsights/onboardingStates (which is an extension resource) to the log analytics workspace resource module. This is primarily a requirement needed for onboarding the log analytics workspace to sentinel.
We currently use this approach in ALZ-Bicep for reference so it would just need to be an empty resource declaration that we could use to scope to the LAW.
(Optional) Correlation Id
No response

@oZakari Thanks for reporting, I will take look at it.


Update version: printfn.fend version 1.4.1

Pull request has been created with Komac v1.11.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

For moderators
This account is automated by Github Actions and the source code was created by CoolPlayLin. If you have any questions about any pull request, don't hesitate to ping @Exorcism0666, I'll get a notification.

[!important]
Please carefully review these Pull Request before merging. If it is a Pull Request for removing incorrect content and the URLs are issue, free upon manual checking, please close this Pull Request directly. (It is best to inform Exorcism0666 of the closure.)

良い一日をお過ごしください！

/AzurePipelines run

Automatic Validation ended with:

Installation failed with exit code -1978335187 2024-01-08 13:16:39.141 [FAIL] Installer failed security check. Url: https://github.com/printfn/fend/releases/download/v1.4.1/fend-1.4.1-windows-x64-exe.zip Result: 0x80004005 2024-01-08 13:16:38.702 [FAIL] Installer failed security check. Url: https://github.com/printfn/fend/releases/download/v1.4.1/fend-1.4.1-windows-x64-exe.zip Result: 0x80004005

(Automated response - build 530.)

/AzurePipelines run

Hi @Exorcism0666,
This manifest adds Apps and Features entries that aren't present in previous PR versions. Should these entries also be added to the previous versions?
(Automated response - build 543.)


[bug]: Channel is stuck in pending state.

Reported by several node runners, Channels which have all their contracts resolved onchain, still do have the channel stuck in the pending state.
The problem is based on the behaviour of the sweeper especially when a sweep is not resolved (pending in the mempool) and lnd restarts.
Example: With force-close leading to an Output (alias Sweeper-Inputs) which is registered with the sweeper engine. So far so good, lets say the fee is not sufficiient enough and the node-runner restarts the node after a while. Lnd does not remember the old sweeps. Now Lnd is relaunching the contract resolvers including the Output from the Force-Close. Very likely that lnd tries to publish the Sweep-Input again but its rejected by the mempool because we already have the Output swept before. The problem is now that LND will try to sweep this Input until MaxSweepAttempts is reached, removing the notification notifier for this input. Now lets imagine the old sweep tx is confirmed. Lnd will not be able to register this spent and the channel will stay in the Pending state forever (user can still abolish the channel but thats another topic).
Problem lies here: https://github.com/lightningnetwork/lnd/blob/master/sweep/sweeper.go#L1373-L1382 => we basically remove the channel which notifies for a spent because we remove the input alltogether.
So we could fix this quick and dirty but I think this should be taken care of in the process of refactoring the sweeper wdyt @yyforyongyu. I think the best strategy is for bitcoind backends to check the input whether its already spent when registering the input with the sweeper. (gettxout  rpc call from bitcoind - including spent in mempool). For other backends  I still have to think about a solution.
I am wondering why the rescan when registering the input with the sweeper did not signal "already spent" when calling waitforspend maybe the look ahead is too short ?

Not sure if this is related or not, but I noticed this from the log in https://github.com/lightningnetwork/lnd/discussions/8007:
Using height hint 809349 retrieved from cache for outpoint=7e26f401a44a5398529032ac50e9a6182a5719fdc0f5630451c2aa7c6c49d585:0, script=0 6eec80ba4a7d32058575c31c24a29946ca03a46c4829be5801c6f5a6b88ae7bd instead of 724383 for spend subscription

This is a channel that on-chain has 50k confirmations for the force-close TX but lnd still sees it as pending. Could it be that our own sweep TX "poisons" our height hint cache and causes us to miss spend notifications?
I see that we try to re-publish the force close TX which gets refused:
2023-09-25 16:47:31.217 [INF] CNCT: Re-publishing force close tx(286d1a06df7ed99dae48636f42ad9bee7d1fcd15e0e31db09517bf68b634e2d1) for channel 7e26f401a44a5398529032ac50e9a6182a5719fdc0f5630451c2aa7c6c49d585:0
...
2023-09-25 16:47:31.232 [INF] LNWL: Inserting unconfirmed transaction 286d1a06df7ed99dae48636f42ad9bee7d1fcd15e0e31db09517bf68b634e2d1
2023-09-25 16:47:31.304 [INF] LNWL: 286d1a06df7ed99dae48636f42ad9bee7d1fcd15e0e31db09517bf68b634e2d1: tx already confirmed
...
2023-09-25 16:47:31.435 [INF] NTFN: New confirmation subscription: conf_id=2, txid=286d1a06df7ed99dae48636f42ad9bee7d1fcd15e0e31db09517bf68b634e2d1, num_confs=6 height_hint=809351
..
2023-09-25 16:47:31.449 [DBG] NTFN: Dispatching historical confirmation rescan for txid=286d1a06df7ed99dae48636f42ad9bee7d1fcd15e0e31db09517bf68b634e2d1

Thanks @guggero and @ziggie1984 for your help in resolving this issue. If this gets implemented in any pre-release branch, I can test it in my current environment with pending channels and let you know the results.

Based on description above there are few questions here,

Now Lnd is relaunching the contract resolvers including the Output from the Force-Close.

lnd shouldn't relauch the resolvers if they are resolved onchain. So the sweep tx should still live in the mempool.

I am wondering why the rescan when registering the input with the sweeper did not signal "already spent" when calling waitforspend maybe the look ahead is too short ?

Since the tx is not confirmed, waitForSpend won't return. I think the look ahead we use here is the broadcast height so it should be fine? Do you have logs showing the output that's causing the issue?
On the sweeper front, we store the sweep tx via NotifyPublishTx so I think we should leverage the sweeper store during startup to reconstruct the pending inputs state.

lnd shouldn't relauch the resolvers if they are resolved onchain. So the sweep tx should still live in the mempool.

lnd will restart the resolver as long as they are not confirmed so when restarting lnd those outpoints will be reoffered, maybe I did not 100% understand the question?

Since the tx is not confirmed, waitForSpend won't return. I think the look ahead we use here is the broadcast height so it should be fine? Do you have logs showing the output that's causing the issue?

You can see in the logs in #https://github.com/lightningnetwork/lnd/discussions/8007 that for example the Force-Close transaction is already confirmed but the height hint got updated and now lnd will not rescan/find the spend, so as guggero said something is poisoning our height_hint

On the sweeper front, we store the sweep tx via NotifyPublishTx so I think we should leverage the sweeper store during startup to reconstruct the pending inputs state.

Good Point I think we could do that, or maybe restructure the db so that we have kind of a map for an outpoint and its potential spending transaction.

@guggero I think a quick fix for @sanjay-shah would be if we add a command in chantools to drop the spend and conf height hint caches, so that a restart would trigger the resolving of all channels ? Not a long term fix but still something which is done quickly ?

Tried to analyse the problem why our HeightHint Cache is filled with garbage data but could not find anything interesting which could cause this behaviour. Normally the HeightHint is updated either if a historical rescan did not reveal the transaction in the blockchain or the transaction is confirmed.
Tho my suggestion is to either reset the Spend/Conf Height Cache when starting up lnd with --reset-wallet-transactions=true, so that we can at least recover the funds if we run into this situation again. Currently we do only drop the transactions so I think it makes sense to include it.

@sanjay-shah while fixing another bug I found the following setting already present in lnd:
--height-hint-cache-query-disable, try starting lnd with this setting, and your funds should be recovered.

@ziggie1984 I ran lnd --height-hint-cache-query-disable.
I did see one transaction being sent to mempool and its also confirmed, It was related expired htlc of one channel closed around one year ago: https://mempool.space/tx/0ce6fe4890977aa4e253e0c3eb2ef3288b5b7ca028eef906c98e5223348a3535
However my lnd has been crashing since I ran it with --height-hint-cache-query-disable option.
Now I can't even run lnd normally. Please see the attached lnd.log And please help urgently as we were scheduled to release our app tomorrow :(
lnd.log

Try updating to lnd 17.0, this has a bugfix for this case.

Ok will take a look, crashes also with 17.0.

I do not remember exactly but why do we not also check for robustness (length of the witness) here, maybe you could help @yyforyongyu : https://github.com/lightningnetwork/lnd/blob/master/contractcourt/htlc_timeout_resolver.go#L377

Evaluating the situation his bitcoind node reveals the following tx information:
bitcoin-cli getrawtransaction 0ce6fe4890977aa4e253e0c3eb2ef3288b5b7ca028eef906c98e5223348a3535
0200000002a72b35f9bcd46bb78c0cf63c6cd2bdc467044d4837ea27f8b905b51d20a6b2be020000000001000000f3f51c7750cbb11033e3b61e6de295ba6f1f0846fd256038e4dcb3c5cf26889f00000000000000000002127a000000000000220020ead078680d77a590ac3f065ce64ce8d9dbe4462b857857fe39d2f6df5ddf7c61410e30000000000022512089a3a0047f3733310a43fa77c55acd855bcec63040d090a055a28ef3377e8acedf960b00

its missing all the witness data.
my fullnode but also mempool.space shows this instead:
02000000000102a72b35f9bcd46bb78c0cf63c6cd2bdc467044d4837ea27f8b905b51d20a6b2be020000000001000000f3f51c7750cbb11033e3b61e6de295ba6f1f0846fd256038e4dcb3c5cf26889f00000000000000000002127a000000000000220020ead078680d77a590ac3f065ce64ce8d9dbe4462b857857fe39d2f6df5ddf7c61410e30000000000022512089a3a0047f3733310a43fa77c55acd855bcec63040d090a055a28ef3377e8ace0500483045022100a1fe9f370ac1fde977ec6a147d8e32f07c8b6f6548667bcc0f6cf5b6a10e4dde02202484ab1a9ec46a075c209c3f1127948e0baa26137b0501a6a51df64ba1cfebbd8347304402204a46f33d8fbe7e51ce462d0099caf66fa2c4a94128d7f0e5d4828de25d13b7f002205ab9a9f8d997033e500ce81bdf6ca21a07262311517266f61e6e452992e91ff401008876a9145a9526206556cafdda02fc05c1da0aa49d2f17bb8763ac67210332bdfbea33e7be2d3d8873b144b401c02aedb13ee2211138406c4d574dc4685c7c820120876475527c210334888d0231807688c2cdb942fb61605b460789605c734539e7d749b652527bbf52ae67a91453d453c8befad357c7de27a98858165e2b7a152388ac6851b27568014011de1eab981fc10d5efcb0543890b9b80851eeba7627226601d2a2ad9675542abad51eb8b1f22b8140eb9db9eccae9a0190e17fb9656b14b8cb7c0c86e98be85df960b00

so we need to also add more robustness for the case where its a local commitment(non-taproot).

Doesn't the lack of witness data indicate an issue with the bitcoind node itself? I agree we shouldn't panic. But this would still warrant a critical (meaning it would trigger a safe shutdown of lnd) error.

Agree with you (we should definitely shutdown safely but shutdown), so his bitcoind is behaving very strange, he is updating now (was on 21), but he was not pruned or something interesting whether an update fixes the issue:
bitcoin-cli getblockchaininfo
{
  "chain": "main",
  "blocks": 813751,
  "headers": 813751,
  "bestblockhash": "00000000000000000002240d0ee6598bae540d6c2a2552967cf3a586fa9edc26",
  "difficulty":<PHONE_NUMBER>3175.59,
  "mediantime":<PHONE_NUMBER>,
  "verificationprogress": 0.9999996602748938,
  "initialblockdownload": false,
  "chainwork": "00000000000000000000000000000000000000005a5a43f64d82a9739fd4cf18",
  "size_on_disk":<PHONE_NUMBER>31,
  "pruned": false,
  "softforks": {
    "bip34": {
      "type": "buried",
      "active": true,
      "height": 227931
    },
    "bip66": {
      "type": "buried",
      "active": true,
      "height": 363725
    },
    "bip65": {
      "type": "buried",
      "active": true,
      "height": 388381
    },
    "csv": {
      "type": "buried",
      "active": true,
      "height": 419328
    },
    "segwit": {
      "type": "buried",
      "active": true,
      "height": 481824
    },
    "taproot": {
      "type": "bip9",
      "bip9": {
        "status": "active",
        "start_time":<PHONE_NUMBER>,
        "timeout":<PHONE_NUMBER>,
        "since": 709632,
        "min_activation_height": 709632
      },
      "height": 709632,
      "active": true
    }
  },
  "warnings": ""
}

I think we've seen this before with a node but couldn't find the issue anymore. I think if the update doesn't work there might be a need to reindex the chain. Not sure if -reindex or -reindex-chainstate is enough, worst case a full reset and starting from an empty data directory for bitcoind might be needed.

#7811 catches this case and gracefully shuts down lnd as it's been reported before occasionally bitcoind won't return the witness.

I think we've seen this before with a node but couldn't find the issue anymore. I think if the update doesn't work there might be a need to reindex the chain. Not sure if -reindex or -reindex-chainstate is enough, worst case a full reset and starting from an empty data directory for bitcoind might be needed.

Thanks @guggero , After updating to 25.1, I'm still seeing the same i.e. no witness data.

I will just spin up a new v25.1 bitcoind full node and see if that fixes the problem.

bitcoind debug.log while lnd crashed.
debug.log

With the bitcoin-core dev help of @maflcko we were able to identify the issue.
When having the bitcoind config option set: rpcserialversion=0, the rpc command will only provide the non-segwit serialization of the transaction, which leads to the above behaviour (no witness data).
According to maflcko this setting will be deprecated in the next release (26) but we will definitely need to highlight it in the docs or even check for this if that's possible.

Aaah, that makes a lot of sense... Thank you so much @ziggie1984 for digging into this! Should we close this issue or do you want to link it to the PR that updates the docs and then close it when merging that?

Yes let's wait until docs are updated.

I am not sure whether we can close this issue tho? Because sanjay main problem was somehow that the height hint cache was updated although funds where not recovered.  I looked into the sweeper code and whether it does somehow poison the height_hint cache but could not reproduce this behaviour. But I have the feeling that this setting  --height-hint-cache-query-disable was introduced because of such a behaviour in the past.
Maybe close this issue and open a more narrowed one which describes the problem with the height hint cache ?

Okay, closing this issue then. @ziggie1984 would you mind creating the issue for the height hint cache? It sounds to me like you might have the most up-to-date context on that. I did a quick scan over our existing issues and there doesn't seem to be one for it yet.


updated readme with local config steps

Updated README file to include setups for running koku backend & frontend-settings locally

Codecov Report

Merging #2268 (8282092) into master (94f44d2) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2268   +/-   ##
=======================================
  Coverage   70.46%   70.46%
=======================================
  Files         400      400
  Lines        7406     7406
  Branches     1624     1624
=======================================
  Hits         5219     5219
- Misses       2155     2159    +4
+ Partials       32       28    -4

Impacted Files
Coverage Δ

src/components/pageTitle/pageTitle.tsx
15.55% <0.00%> (ø)

src/components/charts/costChart/costChart.tsx
10.76% <0.00%> (ø)

...omponents/charts/dailyCostChart/dailyCostChart.tsx
9.09% <0.00%> (ø)

...nts/reports/reportSummary/reportSummaryDetails.tsx
13.26% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 94f44d2...8282092. Read the comment docs.


Improve path merging for non-filled paths

If two paths are not filled, it does not matter whether they intersect or not and they can be merged. This helps with the common case of many different "lines" (which have no fill) that will fail to be merged if they intersect, which is common in many graphics.
With this change many of my files I got another 10% size reduction, because path merging almost always failed for my non-filled paths in "crowded" svgs..

Hi please rebase and add tests

@yGuy Any update on this? Sounds promising and would be good to get it merged in.

Sorry, no time for this, right now. But anyone can rebase and add tests. It doesn't have to be me.


Atom Integration with KDE QT kwallet password manager

(re-opened/copied issue from https://github.com/atom/atom/issues/17575 for 1.28)
Current Atom releases do not use the kwallet password manager when operated in a QT/kde environment (eg. OpenSUSE or Kubuntu). Instead atom calls gcr-prompter from Gnome and then starts gnome-keyring-daemon. But on a KDE system (plasma 5) normally there is no Gnome keyring, all passwords are stored through kwalletd instead. There should be a connector to kwallet and also a possibility to select the password manager through config.

Ahh sorry for losing track of that one @thommierother - going to close this in favor of #17575 since it has more details and then move that issue to https://github.com/atom/node-keytar and we can go from there


How to get the depth from the depth buffer?

I am new to blender python.
The depth image generated is normalized? right?
So if I want to know the min depth and max depth of the depth image. How to do it?
Best regard,
George Yang

What do you mean by "normalized"?
The script places the object at (0, 0, 0), then places the camera at (0, 1, 0.6) and rotates around the object. The depths produced are to be understood in this coordinate frame.
For .png images, there's additional scaling to have the depth fit nicely in the range [0, 255]. If you want raw values, specify --format=OPEN_EXR. Values there should be between 0 and infinity.

Closing due to staleness.


[FLINK-17910][e2e] Fix debug log output to investigate rare test failure

What is the purpose of the change
The associated JIRA ticket is actually some test instability, and this change won't fix the instability. But we can not debug a failed Flink job without access to the logs.
This change fixes the access to the logs. The problem was that grep "cluster" didn't match with the now-uppercase "Cluster" string.
This change makes the grep case insensitive.

Thanks a lot for the review. I'll merge the change.


Global Settings: Server URL: "Use the default value" is unresponsive

Setup

Rancher version: v2.9-head
Rancher UI Extensions:
Browser type & version: Any

Describe the bug
The user is unable to restore the original server URL value after updating it. Clicking the "Use the default value" is unresponsive upon click.
To Reproduce

Go to Global Settings page
Scroll down to server-url section
Click on the three dots menu and click "Edit Setting"
Update the value (i used 'https://e2e-test.com')
Click "Save"
Scroll down to server-url section
Click on the three dots menu and click "Edit Setting"
Click on "Use the default value" button

Result
The user cannot restore the original server URL value after updating it.
Expected Result
The user can restore the original server URL value after updating it.
The reset button should be disabled since there is no default value for server-url
Screenshots
https://github.com/rancher/dashboard/assets/127343932/e6a3d443-67b1-4d65-be68-055be1a32b30
Additional context
When this is fixed please remove '.skip' from the corresponding e2e test to reenable it. (cypress/e2e/tests/pages/global-settings/settings-p2.spec.ts ->> "can update server-url")

The process of changing the server url is not trivial, could you take a look at the documentation and check if updating it and then chaning to default would work?
https://www.suse.com/support/kb/doc/?id=000020173

e2e tests are sufficient. closing cc: @izaac


Log out menu item

The MySkills WebApp should offer the user a possibility to log out from the application. There is already a dummy menu item in the user menu.
Logout should be performed using the OAuthService from the angular-oauth2-oidc module. This service provides a logOut method which removes all tokens and redirects the user to the log out URL of the authorization server to promote single-sign-off.
See https://manfredsteyer.github.io/angular-oauth2-oidc/docs/injectables/OAuthService.html#logOut

PR #20


Autoplay doesn't work

Autoplay doesn't work on IOS release build (reproduce on IPhone 12 Pro Max, but not on IPhone X with the same IOS version 15.5). Autoplay works on the iOS simulator, but if I move app to background and open again animation does not autoplay. It's very stranger issue, may be related to device performance, looks like in some case auto play trigger little bit earlier than it needed, it's just my prediction.
@emilioicai Repo with reproducible demo app -> https://github.com/tarasvakulka/lottie-example-app
There are two ways to reproduce:

Just move app to background and open from background again - animation does not autoplay. For comparing, on "lottie-react-native": "4.1.3" this bug doesn't appear.
Build release .ipa and open it on IPhone 12 Pro Max IOS 15.5, immediately after app launch you can see that autoplay doesn't work, because animation doesn't play (I also tested on IPhone X and this way doesn't work for it, only first one with move to background and reopen).

"react": "17.0.2",
"react-native": "0.67.4",
"react-navigation": "3.11.1",
"lottie-react-native": "5.1.3"
"lottie-ios": "3.2.3"

Might be related to https://github.com/lottie-react-native/lottie-react-native/issues/832


non-descriptive Error in SHA2 when installing

I'm facing a wierd exception about SHA2 installation, when calling "cabal install". the description ends with ExitFailure1 !!
Attached is the log file
sha2.txt

This is not a Juno issue, but an 'installing sha2 on windows issue' and is likely caused by Windows. I have no plans to ever actively support Windows for Juno through would be happy to include info about how to build it for windows if you provide it to me.
I'd recommend first attempting to build Juno via stack because it's a quick test to perform and may just work. If that fails I'd personally give up, install VMWare w/ Ubuntu and play with Juno there.
If you really feel like solving it @cartazio may have some ideas.

The error log seems to be related to related to certain c types not being supported by whatever c compiler you're using.  So it's a sha package issue.  Report it there.  Probably fixed in some newer version of that package that's not in your stack version. Or it's a big you should report to them.

*bug

Thank you guys for the support. I'm gonna trace the bug there at SHA


reinstall with trusty, need a mirror?

Please paste the output of the following command here: sudo edit-chroot -all

no chroots
Please describe your issue:
was having trouble with my previous release (xenial). i wanted to install a new chroot with trusty but it says i need a mirror? not sure what this means tbh...
chronos@localhost / $ sudo crouton -r trusty -t xfce
WARNING: trusty has reached upstream end-of-life.
That means there will be no package updates available.
You also have to specify a mirror to crouton (-m) for installation to proceed.

@zuotian3619,
It means that the trusty release has reached its end-of-life and normal distro channels are no longer available so trusty should be avoided.
If you still want to use it you can find mirrors here: https://launchpad.net/ubuntu/+archivemirrors
Hope this helps,
-DennisLfromGA


Players stuck in queue

Occasionally, when the destination server goes from full to having plenty free space, players are stuck in the queue and not sent in, requiring them to relog. Need to look into this.
Most likely to do with players not being added to the correct queue when they join, but still being sent to the queue server as the server is not over capacity.

Additionally, players still in the queue after a destination server restart need to be handled somehow.

Original issue still occurs after a proxy server restart. The queue is active even though the number of players is far less than the capacity of the slot type.
It looks like this issue is a result of too many players joining after a restart and some players relogging very quickly and being assigned to another slot without being removed from their previous slot. This needs further investigation and if it is found to be the cause, a new issue will be opened to deal with it.
For now, using NCP to limit the rate of rejoins after a restart seems to have resolved the issue.

Issue confirmed, moved to https://github.com/nitricspace/MatsuQueue/issues/9 since unrelated to original issue.


[$500] Threads - Deleted message in thread does not disappear

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.1-7
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:

Chat a chat between User A and User B
Send a message using user A
Go to reply in thread and send a message using User A
Go to User B and open the Thread of the message sent.
While both User A and User B are in the thread chat
Delete The thread or reply message from user A.
Notice that the Deleted reply message does not disappear from user B

Expected Result:
The Deleted reply message immediately disappears from user B
Actual Result:
The Deleted reply message does not disappear from user B
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/5042e0d4-077e-4c97-b22b-5dbb8352035f
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01eb63afab2bfc886f
Upwork Job ID:<PHONE_NUMBER>599926272
Last Price Increase: 2023-11-29

Pusher doesn't update reportActions of thread chat. We need to fix this issue from Pusher side

This looks like a backend issue
Please check the screenshot
The pusher events should include the updates of both parent report action of the thread and the report action of the thread, but it includes only the update of parent report action. This is the root cause
I think this is a backend only issue

Sorry I missed your comment about this being a Backend issue! I've just applied the Engineering label to get some eyes on it.

@tylerkaraszewski are you able to take a look at this one?

Bumping this for Melvin

@tylerkaraszewski how's this going?

It has ended up on the back burner, to be honest.

Totally understood. I'll keep bumping this to satisfy Melvin. Please keep me posted on your bandwidth to take a look!

Bumping for Melvin. How are things looking, Tyler?

@tylerkaraszewski bump!

I'm going to downgrade this to Monthly while we wait on other things to get cleared off Tyler's plate.

Sorry, I haven't even looked at this as I've got two wave issues and a bunch of other chores I'm splitting time between. Downgrading to monthly implies that nobody is super bothered by this, so I'll leave it, but ping me if it's a big deal for anyone.

Thanks for your note, @tylerkaraszewski! I totally get this being deprioritized for wave issues. I've applied the retest-weekly label to see if this behavior still exists. If it does, I'll ask in an internal channel about the priority of this issue in the context of the higher-priority issues.

Issue is reproducible during KI retests.
https://github.com/Expensify/App/assets/43995119/928e4cdb-e882-43ba-b16f-b21429c7425c

It looks like this still exists as of 3 weeks ago and I guess it would be nice to fix but it's still not at the top of anyone's priority list.

Will post about this in Slack today.

Ugh, the Monthly label threw me off. I'm going to get a retest now. If this persists, I may bring this to one of our agencies.

Issue is no longer reproducible
https://github.com/Expensify/App/assets/93399543/23df869c-91c4-483d-927d-46661ed2cb46

Great! Thanks for retesting!


Bump rev to avoid missing goma_ctl

resolves #1

fixed with https://github.com/rouault/pdfium_build_gdal_3_10


Expand on resolutions to transaction is too large to complete; try splitting into pieces error

Describe the problem
A customer recently received the error transaction is too large to complete; try splitting into pieces when attempting to use transactions to delete information.
We only reference this error in Build a Python App (https://www.cockroachlabs.com/docs/v2.1/build-a-python-app-with-cockroachdb-sqlalchemy.html#break-up-large-transactions-into-smaller-units-of-work).  In this case, the error wasn't resolved with the advice contained due to the specific customer steps.
For large deletes, the customer uses two transactions: first fetches session id's from select and it is passed in the delete in the 2nd.
We resolved this problem by adding FROM add  AS OF SYSTEM TIME '-1h' in the Select ( https://www.cockroachlabs.com/docs/stable/as-of-system-time.html)
This allows users to reduce contention since the deletes do not need to occur in realtime.
We should expand out our documentation on this error and this solution.
Also worth noting that Follower Reads is a superior solution to the AOST.

Thanks, @awoods187! Sounds like we need to at least both expand the sql alchemy guidance and add this error to https://www.cockroachlabs.com/docs/stable/common-errors.html.

FWIW, we've improved our DELETE docs to cover large deletes with an AOST query: https://www.cockroachlabs.com/docs/stable/delete.html#batch-delete-on-a-non-indexed-column.

FWIW, we've improved our DELETE docs to cover large deletes with an AOST query: https://www.cockroachlabs.com/docs/stable/delete.html#batch-delete-on-a-non-indexed-column.


@gridsome/source-contentful locales not considered.

In order to retrieve locale-based content with Contentful, the locale i.e. 'en' needs to be passed as part of the GraphQL.
Currently, it doesn't appear that locale has been considered as part of the '@gridsome/source-contentful' package. Only 'id' and 'path' are available.

I'm new on Gridsome, and first I would like to thanks the Gridsome team and contributors for doing such a great job 👍
About this issue that @sliktrik mentioned, I have the same problem. I'm building a website in 2 locales using Contentful as data source, and only the "default" locale is imported and available in Gridsome GraphQL. For example in Gatsby, there is a "node_locale" field that comes, that we can use for filtering the nodes.
Do you plan to add the multi locales support soon? Thanks

Had similar issues in the past. Had to move the project to Gatsby. I'd like to know if anyone has a solution to this problem. Basically makes Contentful sites with multiple locales unusable with Gridsome.

I have spent way too much time figuring this out. Please add support for locales or at least state that there is none.

any updates on this?

I created a pull request now that solves this problem.
Further I'm working on a plugin that automatically creates localized pages (similar to gridsome-plugin-i18n) from the Contentful source. As soon as I'm done I will post it here. ☺

I ended up adding multi-language support for the Contentful source now, see (#1341). You can use it in combination with gridsome-plugin-i18n, works perfectly together.

any news?

@93lucasp As already mentioned in my previous post, this problem is pretty much solved here


CI: migrate 12-policy-import fully over to Ginkgo CI

Signed-off by: Ian Vernon<EMAIL_ADDRESS>

test-me-please

test-me-please


[Documentation Update]: Add a Table of Contents.

Is there an existing issue for this?

[X] I have searched the existing issues

Issue Description
Add a Table of Contents to the Stackoverflow Analysis Guidelines to enhance navigation and improve the overall user experience.
The current documentation is comprehensive but can be challenging to navigate due to its length. A Table of Contents will help users quickly find the sections they are interested in.
Suggested Change
Insert a Table of Contents at the beginning of the documentation, right after the initial badges, and before the "Demo Video" section. The Table of Contents should link to the following sections:
Demo Video
Prerequisites
Installation Steps
Development
Finding Insights from Stack Overflow Developer Survey
Project Goals
Data Source and Background
Data Format
Expected Work
Contributing
License
Thanks to all Contributors
Support
Rationale
A Table of Contents is beneficial as it allows users to quickly navigate to the specific sections they need, improving the usability and accessibility of the documentation. This is particularly important for new contributors who may be looking for specific information on how to get started or understand the project's goals.
Urgency
High
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC contributor
[X] I want to work on this issue
[X] I'm willing to provide further clarification or assistance if needed.

@sanjay-kv can you assign this issue to me?

Fix the badges has well. This might involve lot of iterations.


RC 6.0.2

:tada: This PR is included in version 6.0.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


csi driver not terminating when requested to delete

After running for some time with operator and driver, I attempted to remove the driver... but mistakenly removed the operator as described here: https://github.com/IBM/ibm-spectrum-scale-csi-operator/issues/68
However, it seems  I'm unable to successfully remove the driver with the same yaml file creating the driver...
[root@c943f4n01-pvt csi-operator-ansible]# ./operator-helper.sh get_pods
+ oc get pods -n ibm-spectrum-scale-csi-driver
NAME                                               READY   STATUS    RESTARTS   AGE
ibm-spectrum-scale-csi-attacher-0                  1/1     Running   0          42h
ibm-spectrum-scale-csi-operator-6ff9cf6979-k2gpd   2/2     Running   0          42h
ibm-spectrum-scale-csi-provisioner-0               1/1     Running   0          42h
ibm-spectrum-scale-csi-vk7kr                       2/2     Running   0          41m
ibm-spectrum-scale-csi-vpz6v                       2/2     Running   0          41m
ibm-spectrum-scale-csi-ww78g                       2/2     Running   0          41m
+ set +x
[root@c943f4n01-pvt csi-operator-ansible]#

Then since, i've tried removing the driver multiple times:
[root@c943f4n01-pvt csi-operator-ansible]# ./operator-helper.sh removeDR
csiscaleoperator.scale.ibm.com "ibm-spectrum-scale-csi" deleted

But pods continue to run:
[root@c943f4n01-pvt csi-operator-ansible]# ./operator-helper.sh get_pods
+ oc get pods -n ibm-spectrum-scale-csi-driver
NAME                                   READY   STATUS    RESTARTS   AGE
ibm-spectrum-scale-csi-attacher-0      1/1     Running   0          42h
ibm-spectrum-scale-csi-provisioner-0   1/1     Running   0          42h
ibm-spectrum-scale-csi-vk7kr           2/2     Running   0          55m
ibm-spectrum-scale-csi-vpz6v           2/2     Running   0          55m
ibm-spectrum-scale-csi-ww78g           2/2     Running   0          55m
+ set +x

it's been around 14 minutes and no changes ... still "Running"
Here's the versions of the images being deployed:
[root@c943f4n01-pvt csi-operator-ansible]# ./operator-helper.sh version
--- POD: ibm-spectrum-scale-csi-attacher-0 ---
  ibm-spectrum-scale-csi-attacher:
    Container ID:  cri-o://6798f2aad5ddc2968368080b52e6d173e4ab6155e4a82b9da133d23c3774dee6
    Image:         quay.io/k8scsi/csi-attacher:v1.0.0
    Image ID:      quay.io/k8scsi/csi-attacher@sha256:e57bb6abf0d78e638f70d38bdb07ee30ffe42d423a14fb2f910c11afab3a5e01
--- POD: ibm-spectrum-scale-csi-provisioner-0 ---
  csi-provisioner:
    Container ID:  cri-o://5334023271ac883db03e032ecf46439c9f98c992272a31a41df4c7edd6caef60
    Image:         quay.io/k8scsi/csi-provisioner:v1.0.0
    Image ID:      quay.io/k8scsi/csi-provisioner@sha256:cd0df00950e7b50154e83e29010eb2f2bfe0b661fb7fdd65c6621e8a49cd2bc0
--- POD: ibm-spectrum-scale-csi-vk7kr ---
  driver-registrar:
    Container ID:  cri-o://39e209f1237d2a3f6344905c3eb79b35b7674349d40872d992ca90f8d23770d7
    Image:         quay.io/k8scsi/csi-node-driver-registrar:v1.0.1
    Image ID:      quay.io/k8scsi/csi-node-driver-registrar@sha256:5ad51d40e6de6762ae9bf2acbcf7117d46c87bc50048a337ce5a5cd6697498b4
--
  ibm-spectrum-scale-csi:
    Container ID:  cri-o://5773bf605f616207c5f8e5674d191ffb1b2fa50ced709dc1e2bd3424adab1893
    Image:         quay.io/ibm-spectrum-scale/ibm-spectrum-scale-csi-driver:v0.9.1
    Image ID:      quay.io/ibm-spectrum-scale/ibm-spectrum-scale-csi-driver@sha256:e5926978bd4f4a553df18fc79ac532037c4e31e3a2cdaa6a5c06014fba02c808
--- POD: ibm-spectrum-scale-csi-vpz6v ---
  driver-registrar:
    Container ID:  cri-o://d71f2b8b96edd5e48cb56ec60843471675ac9efcc7b7615c9fa20baa34810e0e
    Image:         quay.io/k8scsi/csi-node-driver-registrar:v1.0.1
    Image ID:      quay.io/k8scsi/csi-node-driver-registrar@sha256:5ad51d40e6de6762ae9bf2acbcf7117d46c87bc50048a337ce5a5cd6697498b4
--
  ibm-spectrum-scale-csi:
    Container ID:  cri-o://bded886e5b2e3aedc0b008bda5499c6572ee6e51681659c9ceb05d3cd2579432
    Image:         quay.io/ibm-spectrum-scale/ibm-spectrum-scale-csi-driver:v0.9.1
    Image ID:      quay.io/ibm-spectrum-scale/ibm-spectrum-scale-csi-driver@sha256:e5926978bd4f4a553df18fc79ac532037c4e31e3a2cdaa6a5c06014fba02c808
--- POD: ibm-spectrum-scale-csi-ww78g ---
  driver-registrar:
    Container ID:  cri-o://e59f0ad8029ae46b4023e28e76226446335fefaccfa8a4cbf2b3265a7409f3a3
    Image:         quay.io/k8scsi/csi-node-driver-registrar:v1.0.1
    Image ID:      quay.io/k8scsi/csi-node-driver-registrar@sha256:5ad51d40e6de6762ae9bf2acbcf7117d46c87bc50048a337ce5a5cd6697498b4
--
  ibm-spectrum-scale-csi:
    Container ID:  cri-o://bce2077dbcca30c17c782b1bb991b2bdef1d6cec645dc91c849eb6554008c689
    Image:         quay.io/ibm-spectrum-scale/ibm-spectrum-scale-csi-driver:v0.9.1
    Image ID:      quay.io/ibm-spectrum-scale/ibm-spectrum-scale-csi-driver@sha256:e5926978bd4f4a553df18fc79ac532037c4e31e3a2cdaa6a5c06014fba02c808

At its core this issue  is that if the operator deployment is deleted without removing the Custom Resource.  I  think this is just a problem with the operator  in general. This  is borderline  wontfix I think.

@mew2057 Why is this tagged as "Documentation"? What should we document?

Closing since this is working as designed


Oauth2 Client expects "expires_in" to be a number

Describe the bug
The field expires_in from the POST /oauth2/token is a string, whereas some system expect a number (example Webswing oidc module) which is using google-oauth-java-client
To Reproduce
public final class OAuth2AccessTokenResponseMapConverter ... {
	@Override
	public Map<String, String> convert(OAuth2AccessTokenResponse tokenResponse) {
		...
		parameters.put(OAuth2ParameterNames.EXPIRES_IN, String.valueOf(getExpiresIn(tokenResponse)));
		...
	}
}

Expected behavior
The field should be a number, in the rfc6749 we can see that the example is using a number instead of a string
   {
     "access_token":"2YotnFZFEjr1zCsicMWpAA",
     "token_type":"example",
     "expires_in":3600,
     "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
     "example_parameter":"example_value"
   }

Thanks for the report @roll57. I logged an issue in Spring Security as this needs to be fixed there. See spring-security#9685.
We might be able to get a temporary fix in here until it's fixed there.


Issues with Datepicker and Bootstrap Modal

See http://codepen.io/jochenberger/pen/rWpQZN
In Firefox 50 on Debian Linux, the select field does not open (or it looks as if the options are hidden). Firefox 45.5.1 on Windows does not work either. Chrome works fine. I have no idea what's happening. :-(

It also works fine in Edge and works... sometimes... in IE11. I wonder if it's a rendering or a JavaScript issue...

Never mind, it's caused by react-bootstrap. The Modal tries to keep focus and that trips Firefox. You can set enforceFocus to false on the Modal. See http://react-bootstrap.github.io/components.html#modals-props-modal

Not sure why this is closed!
The suggested answer by @jochenberger compromises the accessibility of the bootstrap modal.
Is there any other solution other than turning off enforceFocus?
Cheers


Session User Engagement Report

Session User Engagement Report
Introduction
This report provides a detailed analysis of user activity statistics sourced from the storage.db of the Oxen Storage Server, with data fetched in the end of October 2023. The report delivers an exhaustive review of user engagement, showcasing metrics for Monthly and Biweekly Active Users at both the individual server and the network-wide scale. It also emphasizes the distribution of user activity, indicating that the top 15% of the most active users account for more than 80% of the message traffic, thus demonstrating a pronounced manifestation of the Pareto distribution.
Data Preparation

A storage server was operated for over a month, after which a local copy of storage.db was procured.
The pubkey_to_swarm_space_position() function, in conjunction with the methodology outlined in Oxen Storage Server Issue #470, was employed to filter out outdated messages. This step is essential to bypass a known bug and to avoid overestimating the number of active users on a single storage server.

Monthly Active User (MAU)
On a Single Storage Server
By ensuring that no obsolete messages were included and by conducting a thorough data cleanup, we were able to tally distinct owner IDs in the message table. Our server interacted with 2,961 active users for the month.
Network-Wide Estimation
To approximate the Monthly Active Users across the entire network, we calculated the swarm space coverage ratio of our storage server.
The ratio was determined by:

Mapping Session IDs to swarm_space_position using pubkey_to_swarm_space_position()
Sorting swarm_space_position and identifying the minimum and maximum values
Dividing the distance between the minimum and maximum swarm_space_position by 2^64, where the denominator denotes the total swarm space.

Consequently, we deduced that our server covers 1/256 of the network space.
By extrapolation, we estimate the network comprises 758,016 (758k) Monthly Active Users (2,961 multiplied by 256).
Biweekly Active User Analysis
We dive deep into biweekly active users because regular user messages have a 14-days Time-To-Live (TTL). Regular user messages were extracted by filtering messages according to their TTL value. This procedure enabled us to focus on regular user messages and to exclude configuration messages.
The refined dataset contained 283,365 messages from 1,917 users over a biweekly span.
Network-Wide Projection
Applying the same coverage ratio as before (1/256), we project that there are approximately 490,752 Biweekly Active Users network-wide. The same scaling factor is applied in the following analysis.
Pareto Distribution of User Activity
Note on Message Ownership: In the current design of Session, when a user sends a message, a copy is also sent to their own swarm; when a user receives a message, their swarm receives the message. The term 'owning' a message encompasses both sending and receiving; this adds a layer of complexity to the analysis, which we will simplify for the moment by aggregating all such activities under general user engagement.
Distribution of Message Ownership Among Users
Our analysis of user behavior within the network has revealed a pronounced imbalance: a relatively small fraction of users are engaged with a disproportionately large share of messages. This aligns with the Pareto Distribution, which suggests that a small number of individuals often account for a large portion of the effects.
The following table illustrates the cumulative percentage of active users in comparison to the cumulative percentage of messages they are engaged with:

Cumulative Percentage of Users (%)
Cumulative Percentage of Messages (%)

0.26
10

0.73
20

1.4
30

2.2
40

3.5
50

5.7
60

9.3
70

15.2
80

26.6
90

100
100

This data indicates that in a two weeks span, about 3.5% of the most active users engage with 50% of the messages, and around 15.2% of users account for about 80% of the messaging activity. A similar distribution was noted when analyzing the data based on message storage size instead of message count.
Distribution of User Activity Across Time Buckets
To better understand how often users are active, we split two weeks' worth of messages into 14 daily groups. We tracked how many days each user engages. Then, we group users with the same number of active days together and counted number of users in each group.

Days Active (out of 14)
Number of Users

1
200,704

2
82,688

3
45,568

4
31,488

5
22,528

6
18,688

7
15,616

8
13,824

9
11,264

10
9,472

11
7,168

12
8,704

13
7,936

14
15,104

The results are displayed in a Pareto chart reflecting user activity frequency.

Our findings show that, out of 491k biweekly active users, 200k (approximately 40%) were active on only one of the 14 days, 83k were active on two days, and so on. Only 15k users consistently engage with Session everyday. It's crucial to distinguish this 15k figure from the Daily Active Users (around 126k DAU) metric, which measures the number of unique users who interact with the app within a 24-hour interval, without any guarantee of their return the following day.
It is also noteworthy that with 758k monthly active users and 491k biweekly active users, there are approximately 267k users who have periods of inactivity exceeding 14 days. This raises a concern that they may miss messages due to the 14-day Time-To-Live (TTL) policy.
Daily Active Users (DAU)
We splitted messages into 14 time-based buckets and calculated the number of daily active users. After scaling up with a factor of 256, we extrapolate a DAU between 111,616 and 137,472 on a network-wide basis. On average, we estimate there are approximately 126,244 daily active users across the network.
DAU / MAU Ratio
The DAU/MAU ratio is a key performance indicator that measures user retention and engagement. For our network, this ratio is calculated as follows: 126,244 / 758,016 = 16.7%.
Comparative Analysis with Other Products
We compare the DAU/MAU ratio of Session with other products:

Product
DAU
MAU
DAU/MAU Ratio
Source
Source Date

Session
126k
758k
16.7%
-
2023-10

Facebook Family
3.14B
3.96B
79%
Meta Earnings Presentation Q3 2023
2023 Q3

SnapChat
406M
750M
54%
Snap Inc. Investor Presentation
2023-10

Brave Browsers
23M
64M
36%
BraveBat
2023-09

Session's DAU/MAU ratio is considerably lower than the industry average, potentially signaling its immaturity. This is further supported by the current average rating of the Session Android app, which stands at approximately 3.6, lagging behind the overall average app rating of 4.0 as reported by AppBrain.
Insights and Considerations

Cross-validation of User Statistics: The official number of monthly Session users is reported using a synthesis formula approach. It would be beneficial to cross-validate this method with other approaches and calibrate parameters as necessary. A discrepancy between different metrics does not necessarily mean one is incorrect. For instance, if the synthesis formula by OPTF yields a higher user count than the Oxen storage server data, it could be that many users download the Session app but struggle with account creation or finding friends to communicate with. Another possibility is that a significant percentage of users are using multiple devices, which would be counted only once when calculated using Oxen storage server data.

Community Perception vs. Official Figures: Persistent doubts among community members regarding their perception of the number of Session users compared to official figures may find some explanation in our Pareto distribution analysis. The most active 3.5% of biweekly users (approximately 17k out of 491k) account for 50% of the messages, which corresponds closely with the 15k users consistently engage everyday, yet this figure is much lower than the total MAU. Moreover, the DAU/MAU ratio for Session is notably lower than what is typical in the industry, which may contribute to the community's perception of a smaller user base.

Potential for Monetization: The concentration of activity among a small group of users suggests that we may be closer to achieving monetization than previously considered. If we target the most enthusiastic users and address their common pain points, monetization could be promissing. Assuming that the willingness to pay correlates with user engagement, the most enthusiastic 17k users, representing 3.5% of biweekly or 2.3% of monthly users, might be willing to pay $5 per month. This could potentially generate close to $1 million in annual revenue.

Openness to New Features: The same group of highly active users may also be more open to trying new features, such as making payments in Oxen. Their willingness to engage with new aspects of the platform could be crucial for the success of Oxen.

Privacy Risks with Token Changes: The significant concentration of activity among a small subset of users raises concerns about the increased risk of deanonymization if the Oxen coin is replaced by a transparent token. If the most active users correlate highly with those most willing to pay, then introducing Session Monetization with a transparent token could either significantly inconvenience these active users or substantially elevate the risk of deanonymization for core users. These core users, who most require privacy, are comparable to the hubs or critical nodes within the network. Making privacy transactions optional would be akin to eliminating mandatory onion routing from the Session network. Should the privacy of these core users be breached, the fallout could extend to their contacts, potentially compromising the privacy of a significant proportion of the network. For further details, see Privacy Implications of Replacing the Oxen Privacy Coin in the ONS Registration Process.

Appendix: Synthesis Formula of MAU from OPTF
Source: https://t.me/Oxen_Community/381121

Simplified Formula
MAU = A + B + C + D + E
A: iOS user numbers
A = 30 Day active users X 2.8571
35% of users opt into providing data through the App Store, so we multiply the provided numbers by 2.8571 (0.35*2.8571=0.999) to find the current MAU details. It is possible—even likely—that Session users opt-in at a lower rate than the average user, but we do not have data to confirm this suspicion, so we take the average.
B: Android Play store numbers
B = MAU here is Unique users over 30 days rolling average daily.
This is a figure provided by the Play Store, no additional calculation required.
C: APK estimated MAU
C.  = Combining downloads on the 5 APK’s available on Github. (This does not include people downloading APKs from unofficial sources or sharing APKs privately). This number is reset with each release, we cannot effectively grab this number more frequently.
D: Estimated Desktop MAU
D = Combine downloads across 6 github repositories from latest release.
We add up all of the latest desktop downloads, and these restart with each release and lag true data.
E: Estimated F-Droid Users
E = (A + B + C + D) * 0.1
From historical community and user surveys feedback, we estimate that 10% of Session manage installation and updates via F-Droid. This number will likely change in the future, if we are able to gather further information or counting methods.

Great

Hey @venezuela01, we recently encountered several issues with the Service Node "oxen storage server" package, which affected user interactions with communities, the Session file server, and even the ability to send 1-1 messages. This period of instability began in early July and was resolved last week. Understandably, many users were frustrated by these disruptions and left 1-star reviews, which we believe is the primary reason for our app's lower rating recently. We are now focused on improving and stabilizing the core experience of the app to restore and surpass our previous rating.
This message describes the state of the network shortly after the Oxen storage server 2.7.0 mandatory Service Node upgrade (MSNU), we have now deployed client and server side fixes in storage server 2.8.0 and initiated a new MSNU.

Regarding the network instability experienced in the last few weeks, the recent MSNU update, which includes a new version of the storage server (2.7.0), has significantly reduced the crash rate of the storage server in production. These crashes were causing significant issues for Session clients sending messages in 1-1s, communities, and when interacting with the Session file server. So far, this update has been deployed to over 85% of Service Nodes and has led to much greater reliability in 1-1 and group chats.
However, as the update rolled out, we did not see the same increase in the reliability of interactions with communities and the file server, particularly during attachment uploads and downloads. These issues also impact link previews and profile images. We investigated these issues over the weekend.
During our investigation, we discovered a problem with how the storage server communicates via HTTPS to non-Service Nodes, i.e., nodes outside the network. The storage server typically only communicates with three external sources: communities, the Session file server and the push notification server. We identified two issues. First, our current implementation of requests from the storage server to external nodes could only handle a small number of simultaneous requests before getting backed up, which would in turn cause further backups. We also identified a deadlock issue in libcpr, a C++ library used for sending those requests (see https://github.com/libcpr/cpr/issues/1040). These issues combined caused requests to frequently timeout and fail when sent to communities and file servers.
To address this, we have refactored how these requests are made to make them asynchronous, which will allow us to use the available resources on all service nodes more efficiently, meaning we can handle a higher volume of simultaneous requests. We have also made changes to our usage of libcpr to avoid the deadlocking issue. These changes should resolve the issues with Session clients communicating reliably with communities and file servers (see https://github.com/oxen-io/oxen-storage-server/pull/501). We have been testing the reliability of this update on foundation Service Nodes and have seen a reduction in failure rates to just 0.008% of requests to communities and file servers, compared to the previous failure rate of nearly 100%.
We will be publishing a new MSNU update tomorrow 2.8.0, including the updated storage server package to resolve this issue. This new MSNU will not affect the current MSNU, which is scheduled to go live tomorrow. Instead, the new MSNU will have a new deadline, after which nodes with the older storage server version will be removed from the network during the next hardfork.

Hey @venezuela01, there are a few things to discuss here that might help clarify the announcement. Firstly, our measurement of MAUs does not rely solely on the count of configuration/regular messages containing unique Session IDs from a selection of Service Nodes over a period of time. Instead, we synthesize data from various sources, including Service Nodes, the Google Play Store, the Apple Store, GitHub, F-Droid, and others.
Why do we do this? Because there are several issues with how different clients post configuration messages to Service Nodes. For example, last week we discovered that Android clients failed to post configuration messages to their swarm when creating new accounts in some cases. This issue was present in all pre-onboarding releases. Other similar cases have been found on iOS and Android linked devices recently, which caused clients not to update their configuration messages at all when multiple devices were linked. While we are actively resolving these issues as they arise, we have not yet confirmed the absolute reliability of configuration messages.
Without a high level of trust in configuration messages, it's possible to miss a significant number of active users if we rely solely on Service Node measurements. For instance, users who are active only in communities or closed groups/groups might be undercounted, as closed groups can share a single "Session ID" from the perspective of Service Nodes. Additionally, users who primarily send messages to others without receiving timely responses might also be underrepresented.
Given this, our primary source for MAU data right now, supplemented by other measures, is the app stores. Google Play provides a statistic called "Monthly Active Users," defined as "the number of users who opened your app in a 28-day period." We use this measure for Google Play, while the Apple Store provides a similar statistic called "Active Last 30 Days," defined as "the total number of devices with at least one session within 30 days of the selected day." The combination of these sources, along with additional measures, produces an aggregate MAU count, which currently exceeds 1 million.


Building requires Meta XR SDK Assets

I think you should update the README.md to say you also need to install the Meta XR SDK unity asset from https://assetstore.unity.com/packages/tools/integration/meta-xr-all-in-one-sdk-269657 after installing Unity.
I can create a PR for this, but I figure it's trivial and you probably have further README changes anyway.
Let me know if you want a PR for this.
Thanks

Thanks for reaching out! The latest revision of the documentation includes a step for adding the XR SDK to the user's Unity account. :)


Fixes #1416

What caused this to break? 3.0.11 -> 3.0.12?

Possibly the fact that I was testing with a dissimilar migration


Multilingual support

https://gohugo.io/content-management/multilingual
I think this would allow for better accessibility.
I can try to move the strings to a English toml file (not sure if wanted)
~ Hard to implement but better then dark mode

I don't plan to work on this due to not being multilingual, help wanted :)