Influxdb crashes after 2 hours

Bug report
System info:
Influxdb 1.1.0
Os: Debian
Steps to reproduce:

Start influxdb
Create 500 different databases with 500 users
Auth should be on

Expected behavior:
Should run normally
Actual behavior:
Crashes after two hours

Crash exception is over 70Mb:
https://www.dropbox.com/s/hn2sde9liw6dbo7/error.log?dl=0

Another link, maybe this will work better:
https://www.dropbox.com/s/1nqioi5pf18gz0q/error2.log?dl=0

At the time of crash, there was 114k goroutines in the system:
grep "goroutine " error2.log|wc -l
114551

Roughly half of them were stuck at the same place:
grep engine.go:979 error2.log|wc -l
56118

goroutine 19985 [sleep]:
time.Sleep(0x3b9aca00)
	/usr/local/go/src/runtime/time.go:59 +0xe1
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Engine).compactTSMLevel(0xc429826100, 0xb74601, 0x1, 0xc428dd2300)
	/root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:979 +0x90

@rubycut Can you attach the full panic?  The two links provided cut off the actual cause of the panic.
Can you also run the following and attach to the issue:
curl -o block.txt "http://localhost:8086/debug/pprof/block?debug=1"
curl -o goroutine.txt "http://localhost:8086/debug/pprof/goroutine?debug=1"
curl -o heap.txt "http://localhost:8086/debug/pprof/heap?debug=1"
curl -o vars.txt "http://localhost:8086/debug/vars"
iostat -xd 1 30 > iostat.txt
uname -a > uname.txt
influx -execute "show shards" > shards.txt
influx -execute "show stats" > stats.txt
influx -execute "show diagnostics" > diagnostics.txt

uname -a
Linux dedxxxx 3.10.95xx #30 SMP Fri Jan 29 11:54:46 CST 2016 x86_64 GNU/Linux

iostat.txt

[ ] curl -o block.txt "http://localhost:8086/debug/pprof/block?debug=1"
[ ] curl -o goroutine.txt "http://localhost:8086/debug/pprof/goroutine?debug=1"
[ ] curl -o heap.txt "http://localhost:8086/debug/pprof/heap?debug=1"
[ ] curl -o vars.txt "http://localhost:8086/debug/vars"
[ ] iostat -xd 1 30 > iostat.txt
[ ] uname -a > uname.txt
[ ] influx -execute "show shards" > shards.txt
[ ] influx -execute "show stats" > stats.txt
[ ] influx -execute "show diagnostics" > diagnostics.txt

shards.txt

dignostics:
name: build
-----------
Branch  Build Time      Commit                                          Version
master                  800da5732b91c816b0a097acf8887fa2af1efa1a        1.1.0

name: network
-------------
hostname
dedxxxx

name: runtime
-------------
GOARCH  GOMAXPROCS      GOOS    version
amd64   24              linux   go1.7.3

name: system
------------
PID     currentTime                     started                         uptime
5324    2016-11-18T20:27:10.806259576Z  2016-11-18T20:01:05.251612142Z  26m5.554647524s

@rubycut Can you attach show retention policies as well?  The number of goroutines is high because it looks like you have 1 day shard group durations for all your shards but fairly large retention range.  You also have a large number of databases as well.

vars.txt
https://www.dropbox.com/s/h5ftawg2ax2baoc/vars.txt?dl=0

@jwilder , show retention policies doesn't work, database must be selected first, so in all databases, retention policy is the same, it looks like this:
> show retention policies
name            duration        shardGroupDuration      replicaN        default
default         0s              168h0m0s                1               false
four_months     3000h0m0s       24h0m0s                 1               true

@jwilder , I attached full panic, there is nothing important before panic, influxdb was writing, business as usual:
[httpd] <ip_hidden> - c3941_telegraf [18/Nov/2016:12:16:03 +0000] "POST /write?consistency=&db=c3941&precision=ns&rp= HTTP/1.1" 204 0 "-" "InfluxDBClient" c6823a4f-ad88-11e6-9ab6-000000000000 98278
[httpd] <ip_hidden> - c3503_telegraf [18/Nov/2016:12:16:04 +0000] "GET /query?db=&q=CREATE+DATABASE+IF+NOT+EXISTS+%22c3503%22 HTTP/1.1" 400 94 "-" "InfluxDBClient" c6939fb5-ad88-11e6-9ac5-000000000000 993
[httpd] <ip_hidden> - c3439_telegraf [18/Nov/2016:12:16:03 +0000] "POST /write?consistency=&db=c3439&precision=ns&rp= HTTP/1.1" 204 0 "-" "InfluxDBClient" c6870f8e-ad88-11e6-9ab9-000000000000 85296
[httpd] <ip_hidden> - c3623_telegraf [18/Nov/2016:12:16:04 +0000] "POST /write?consistency=&db=c3623&precision=ns&rp= HTTP/1.1" 204 0 "-" "InfluxDBClient" c693d5fa-ad88-11e6-9ac6-000000000000 2071
unexpected fault address 0x0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x40ea9d]

curl "http://localhost:8086/debug/pprof/goroutine?debug=1"
404 page not found

pprof is not working, I am using stock influxdb 1.1.0 downloaded from your side, do I need to recompile or use anything else to turn pprof on?

@rubycut Can you attach the full trace?  That tells me what the panic was, but not where it occurred or what else was going on at the time.
For your shards, I'd recommend using a larger shard group duration.  For a four month retention period, a shard group duration of 1 mon would significantly reduce the number of shards and goroutines running on your system.   The number of databases compounds the problem as well.  The shards don't look very big so smaller shard durations is likely just creating overhead for little benefit.
It looks like you may be using a custom kernel as well which might be having problems with the number of goroutines/shards/etc.. or other dependent system resources associated with them.

You may need to set:
[http]
pprof-enabled = true

stats.txt:
https://www.dropbox.com/s/nux9u48fgiuul6i/stats.txt?dl=0

@jwilder , when influxdb crashes, it writes state in the log, this is what I already sent you, I don't know any other way how to obtain full trace.

@rubycut The two dropbox links only have the end of the trace.  The beginning part is cut off which doesn't indicate what the panic was or where it occurred.  This is all I see:
x197

goroutine 119256 [sleep]:
time.Sleep(0x3b9aca00)
	/usr/local/go/src/runtime/time.go:59 +0xe1
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Engine).compactCache(0xc6aeb83800, 0xc727eece40)
	/root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:953 +0xd7
github.com/influxdata/influxdb/tsdb/engine/tsm1.

... rest of trace...

oh man, dropbox sucks, here is the gist of trace:
https://gist.github.com/rubycut/d35daf01887b5d23ddd4571c500c8e64

I added this:
[http]
pprof-enabled = true

pprof links still don't work.

As we changed shardGroupDuration from one day to two weeks, number of goroutines is going down, we are at 111k goroutines, they go down by 1k each day.
Today, influxdb was running for 4.5 hours without going down.

But we are observing strange memory behavior compared with influxdb version 0.13.
Blue line is Influxdb 1.1.0, while green is influxdb 0.13, both servers are running same load.
As you can see influxdb 1.1.0 has constantly rising memory footprint, and in many cases I suspect that memory could be cause of crash, although server doesn't seem to die from OOM killer.
Sudden drop in blue line every couple of hours

This is after running for 50 minutes:
goroutine.txt: https://gist.github.com/995cd72876f8638447fab50af25995d5
block.txt: https://gist.github.com/d3b83295fa62e931af14f77298d57427
heap.txt: https://gist.github.com/595f25f3f77f3e597e060ec9d73a314b

@jwilder , I added all the info you required. I am standing by if you need anything else.

This is prior to crash: https://gist.github.com/rubycut/a30c2351664424189e312e168154629e

Here is the pprof heap map as it is getting full:
https://gist.github.com/b036527bc1163a7f52b0de6fa7fd2a6b

@jwilder , it seems that
defaultWaitingWALWrites = 10 could be bottleneck, look at:
https://github.com/influxdata/influxdb/blob/v1.1.0/tsdb/engine/tsm1/wal.go#L71
is it safe for me to increase this value and recompile?

@rubycut Increasing it could cause higher memory usage.   You may want to try lowering it since you have a lot of databases and shards.

I can't get it to work, if I reduce it to 5, or increase it, it always grows as visible in this heatmap.

I brought memory under control with  cache-snapshot-memory-size = 2621440
Still, it crashes every two hours with:
influxd.log.7-panic: runtime error: invalid memory address or nil pointer dereference
influxd.log.7-[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]
influxd.log.7-
influxd.log.7-goroutine 92627 [running]:
influxd.log.7-panic(0x9cf120, 0xc4200120b0)
influxd.log.7-  /usr/local/go/src/runtime/panic.go:500 +0x1a1
influxd.log.7-created by github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Engine).enableLevelCompactions
influxd.log.7-  /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:214 +0x113
influxd.log.7-[signal SIGSEGV: segmentation violation code=0x2 addr=0xc6634fb180 pc=0xc6634fb180]
influxd.log.7-
influxd.log.7-goroutine 39672 [running]:
influxd.log.7-runtime.throw(0xa7c76c, 0x5)
influxd.log.7-  /usr/local/go/src/runtime/panic.go:566 +0x95 fp=0xc7e9024e68 sp=0xc7e9024e48
influxd.log.7-runtime.sigpanic()
influxd.log.7-  /usr/local/go/src/runtime/sigpanic_unix.go:27 +0x288 fp=0xc7e9024ec0 sp=0xc7e9024e68
influxd.log.7-created by github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Engine).enableLevelCompactions
influxd.log.7-  /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:215 +0x13f
influxd.log.7-

I setup 500 databases each with their own user and a telegraf instance. Each database also has a retention policy with a 4 month duration and a 1 day shardGroupDuration (not ideal but trying to repro the original problem)
It has been running for 2 hours and hasn't crashed yet but I do see a lot of memory used. I'm at almost 12GB currently.
go tool pprof http://localhost:8086/debug/pprof/heap
Fetching profile from http://localhost:8086/debug/pprof/heap
Saved profile in /home/allen/pprof/pprof.localhost:8086.inuse_objects.inuse_space.013.pb.gz
Entering interactive mode (type "help" for commands)
(pprof) top10
11.27GB of 11.32GB total (99.57%)
Dropped 564 nodes (cum <= 0.06GB)
Showing top 10 nodes out of 27 (cum >= 0.12GB)
      flat  flat%   sum%        cum   cum%
    5.02GB 44.40% 44.40%     5.02GB 44.40%  github.com/influxdata/influxdb/pkg/pool.(*Bytes).Get
    3.83GB 33.86% 78.26%     3.83GB 33.86%  github.com/influxdata/influxdb/tsdb/engine/tsm1.(*entry).add
    2.28GB 20.13% 98.39%    11.16GB 98.65%  github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Engine).WritePoints
    0.12GB  1.06% 99.45%     0.12GB  1.08%  github.com/influxdata/influxdb/services/httpd.(*Handler).serveWrite
    0.01GB  0.12% 99.57%     3.86GB 34.12%  github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Cache).write
         0     0% 99.57%     0.12GB  1.09%  github.com/bmizerany/pat.(*PatternServeMux).ServeHTTP
         0     0% 99.57%    11.18GB 98.78%  github.com/influxdata/influxdb/coordinator.(*PointsWriter).WritePoints.func1
         0     0% 99.57%    11.18GB 98.78%  github.com/influxdata/influxdb/coordinator.(*PointsWriter).writeToShard
         0     0% 99.57%     0.12GB  1.08%  github.com/influxdata/influxdb/services/httpd.(*Handler).(github.com/influxdata/influxdb/services/httpd.serveWrite)-fm
         0     0% 99.57%     0.12GB  1.09%  github.com/influxdata/influxdb/services/httpd.(*Handler).ServeHTTP

@allenpetersen Can you try changing https://github.com/influxdata/influxdb/blob/master/tsdb/engine/tsm1/pools.go#L10 to use 10 instead of 1024?
I think the pkg/pool may need to free up some resources if they haven't been used or drop them if they are excessively large.   Alternatively, the pool size should probably be much lower since the WAL uses a 4MB buffer by default.
The WAL bytes pool was switched from a sync.Pool to pkg/pool in #7348.  Things in a sync.Pool will get garbaged collected whereas the pkg/pool will not.

@allenpetersen , we don't use all the databases, so 170 databases would be enough. In each of these databases, we write from 5-100 servers, let's say 20 servers is average, so 3000 telegraf clients writing will be hard to simulate. Check into _internal database, https.pointsWrittenOK is around 2700 writes per second, that is the load you have to achieve to emulate.
With this load, heap grows constantly it starts from 7.5 Gb of memory, goes upto 26 Gb in 100 minutes. Which is around 200 Mb per minute. That is definitely more than expected, but since server has 64Gb of RAM, memory growth is not the only bug.

After server was running for over an hour, I execute:
curl -s http://ded6350.ded.reflected.net:8086/debug/pprof/heap > current.heap
sleep 120
curl -s http://ded6350.ded.reflected.net:8086/debug/pprof/heap > current2.heap
go tool pprof --base current.heap /workbench/bin/influxd current2.heap

And result is:
ROUTINE ======================== github.com/influxdata/influxdb/pkg/pool.(*Bytes).Get in /workbench/src/github.com/influxdata/influxdb/pkg/pool/bytes.go
  432.08MB   432.08MB (flat, cum)   100% of Total
         .          .     20:func (p *Bytes) Get(sz int) []byte {
         .          .     21:   var c []byte
         .          .     22:   select {
         .          .     23:   case c = <-p.pool:
         .          .     24:   default:
      -8MB       -8MB     25:           return make([]byte, sz)
         .          .     26:   }
         .          .     27:
         .          .     28:   if cap(c) < sz {
  440.08MB   440.08MB     29:           return make([]byte, sz)
         .          .     30:   }
         .          .     31:
         .          .     32:   return c[:sz]
         .          .     33:}
         .          .     34:

Notice that I didn't use -alloc_space option, which means this is extra memory taken in two minutes.
So, although it has a pool, it doesn't seems to use byte slices from pool, it uses make to allocate new ones.
I will also try now with pool size 10.

@jwilder , by decreasing pool size, memory growth issue is completely eliminated. I set both pool size and defaultWaitingWALWrites to 24, that is the number of cores.
However, influxd is still crashing every two house.

@jwilder , do you want pull request?

@rubycut A pull request for the setting pool size to 10 would be good. For defaultWaitingWALWrites', maybe something like:  defaultWaitingWALWrites = runtime.NumCPU()` would be more portable.

@rubycut The pool allocations you see in the profile can occur if the slice returned from the pool does not have enough capacity for what was requested.  For example, it got a 10mb slice, but a 25mb slice was requested so we allocate a new one.  The new one should get added to the pool again when it's not in use.  My guess is that a pool size of 1024 was eventually holding onto some very large slices which consumes a lot of memory.

@jwilder , I'll make pull request now.
As far as crashes are concerned, which still continue to happen every two hours, just before influxd crashed last time, we had huge 5 second lockup:

@rubycut I'm not sure what to make of that.  That call trace is what happens at startup when loading shards.  I'm not sure how you would see that just before it crashed.
BTW, how did you generate that image?  What tool is that?

@jwilder , you are right, this could already be startup since instance is automatically restarted with supervisor.
Tool is relatively new, https://stackimpact.com/

@jwilder I've been digging into the memory usage. At least in this 500 database config the size of the requested buffers varies quite a bit resulting in a large amount of reallocating which prevents the pool from doing a good job.
I've been experimenting with making 4 different pools each with a different buffer size. All buffers in that pool are allocated with the same capacity so there isn't a need for reallocating. After analyzing the requested buffers here are the pool sizes that work well for this test config.
small 500KB buffers
medium 1MB buffers
large 4M buffers
XL unlimited (use requested size) I see a handful of 11 and 13MB requests
Under the load test for 30 minutes I'm only seeing 151MB being retained by the pools in total. Most of the activity is in the small and large pools at about 50-100 requests per second each.
The XL pool only has 1 item and has only gotten accessed 189 times in 40 minutes. I've thought about not pooling the XL requests but it is only using up 13MB of RAM but it is preventing heap fragmentation by not having to reallocate that same block.
The medium pool got used a lot at startup time and then leveled off. I think that size must get used while reading in the cachloader.
Here are the pool stats after running for about 40 minutes under load
Size    Held (MB)  Requests
Small       14      382803
Medium       8      350591
Large      116       36119
XLarge      13         189
Total      151      769702

@allenpetersen Interesting.  Would you be able to try reverting the pool back to sync.Pool?  This is the code that was there before: https://github.com/influxdata/influxdb/pull/7348/files#diff-25cc809730c7e22463531e3af8bf5dec

I was looking at that code and I agree that sync.Pool might not be the best fit because the pools can get cleared often. The thrashing I was seeing with bufPool is gone with the bucketed sizes and Bytes.Get() is really low on the inuse_objects list. I've had influx under load for 70 minutes and it is quite happy, memory isn't growing.
Here is the WIP commit, there is a lot of logging code I've been using to monitor the pools
https://github.com/allenpetersen/influxdb/commit/cf76c3ee4f14055a4bb1a08dace9d3879f6c2721
I'm still looking into what seems like a heap fragmentation issue. Linux is reporting 30GB virtual and 11GB resident and there is 16GB of HeapReleased RAM.
# runtime.MemStats
# Alloc =<PHONE_NUMBER>
# TotalAlloc =<PHONE_NUMBER>08
# Sys =<PHONE_NUMBER>0
# Lookups = 454114
# Mallocs =<PHONE_NUMBER>
# Frees = 868244704
# HeapAlloc =<PHONE_NUMBER>
# HeapSys =<PHONE_NUMBER>6
# HeapIdle =<PHONE_NUMBER>4
# HeapInuse =<PHONE_NUMBER>
# HeapReleased =<PHONE_NUMBER>6
# HeapObjects = 199958653
# Stack = 32309248 / 32309248
# MSpan = 140084000 / 220659712
# MCache = 9600 / 16384
# BuckHashSys = 1721121

@jwilder I quickly swapped out pool.Bytes with sync.Pool and it's performing really well.
https://github.com/allenpetersen/influxdb/commit/dd71b23513e42edd3ff25cfb918faac1491768a0
I'll get exact numbers here in a bit but for example with the older code it took almost 2 minutes to finish the cachloader stage of startup. With sync.Pool it took 15 seconds.
Linux is only reporting 10GB virtual and 4.4GB resident, each about 1/3rd of the older code.
# runtime.MemStats
# Alloc =<PHONE_NUMBER>
# TotalAlloc =<PHONE_NUMBER>8
# Sys =<PHONE_NUMBER>
# Lookups = 209778
# Mallocs = 291427402
# Frees = 235183224
# HeapAlloc =<PHONE_NUMBER>
# HeapSys =<PHONE_NUMBER>
# HeapIdle =<PHONE_NUMBER>
# HeapInuse =<PHONE_NUMBER>
# HeapReleased = 37691392
# HeapObjects = 56244178
# Stack = 34897920 / 34897920
# MSpan = 50029920 / 57786368
# MCache = 9600 / 16384
# BuckHashSys = 1627555

@jwilder After 70 minutes with sync.Pool things continue to look really good. Overall it seems to be using about half of the memory as before.
Here are the results for a 70 minute test with sync.Pool buckets.
# runtime.MemStats
# Alloc =<PHONE_NUMBER>
# TotalAlloc =<PHONE_NUMBER>6
# Sys =<PHONE_NUMBER>
# Lookups = 779259
# Mallocs = 723575666
# Frees = 624965997
# HeapAlloc =<PHONE_NUMBER>
# HeapSys =<PHONE_NUMBER>
# HeapIdle =<PHONE_NUMBER>
# HeapInuse =<PHONE_NUMBER>
# HeapReleased = 0
# HeapObjects = 98609669
# Stack = 35028992 / 35028992
# MSpan = 67064000 / 75710464
# MCache = 9600 / 16384
# BuckHashSys = 1696723
# NextGC =<PHONE_NUMBER>
# PauseNs = [530289<PHONE_NUMBER>96 1096046<PHONE_NUMBER>90<PHONE_NUMBER>29<PHONE_NUMBER>54<PHONE_NUMBER>67<PHONE_NUMBER>08 91926 68829<PHONE_NUMBER>2<PHONE_NUMBER>35 81930<PHONE_NUMBER>5 52479 55663<PHONE_NUMBER>11 69988<PHONE_NUMBER>78<PHONE_NUMBER>5<PHONE_NUMBER>3<PHONE_NUMBER>39<PHONE_NUMBER>11<PHONE_NUMBER>2<PHONE_NUMBER>29<PHONE_NUMBER>96<PHONE_NUMBER>19<PHONE_NUMBER>745<PHONE_NUMBER>79<PHONE_NUMBER>523 1180971 1252676 1633985 2201706 3144175 3008831 3424641 3293706 3314497 4204496 3700088 3804114 8579937 4113989 4518797 3754106 3912663 3819891 4386894 3742700 4217162 3866343 4455789 4059505 4565848 4185661 1892691 3760559 4036164 4194639 4772064 4188802 5763421 4162223 4569555 4053164 5886723 3843425 4263090 4310646 7016731 5057678 4185530 3967028 4009587 4095376 4807964 4115051 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
# NumGC = 100
# DebugGC = false

I'll do a similar run with 1.1.0 now.

Here is a comparison of 1.1.0 to master+sync.Pool buckets
                 1.1.0       sync.Pool    delta
Alloc<PHONE_NUMBER><PHONE_NUMBER>    58.09%
TotalAlloc<PHONE_NUMBER>00<PHONE_NUMBER>6    89.25%
Sys<PHONE_NUMBER>4<PHONE_NUMBER>    57.67%
Lookups           748249        779259   104.14%
Mallocs        933161203     723575666    77.54%
Frees          767299281     624965997    81.45%
HeapAlloc<PHONE_NUMBER><PHONE_NUMBER>    58.09%
HeapSys<PHONE_NUMBER>8<PHONE_NUMBER>    57.51%
HeapIdle<PHONE_NUMBER><PHONE_NUMBER>    54.29%
HeapInuse<PHONE_NUMBER><PHONE_NUMBER>    58.70%
HeapReleased<PHONE_NUMBER>             0
HeapObjects    165861922      98609669    59.45%

@jwilder I ran a few more tests and using fixed size sync.Pools worked best. Unfortunately there is a lot of variability between the test runs. I want to make a repeatable workload with influx_stress to better compare the different mechanisms before making a PR.

@rubycut @allenpetersen there are a couple of problems with the current pool in pkg/pool`.
@rubycut's fix in #7683 will help with memory management for systems under load with occasional large buffer requirements but the cost is increased allocations due to more contention over the now smaller pool.
@allenpetersen we originally used sync.Pool but I believe the issue with very high loads was that it was aggressively releasing items back to be GC and so the number of allocations was quite high. I think the tradeoff from going from a sync.Pool backed pool to a fixed channel backed pool was to reduce allocations with the cost of increased memory usage.
I've been working on a new pkg/pool which will tracked requested buffer sizes and dynamically release buffers from the pool if they're not appropriately sized. I'm hoping it will give us the best of both worlds (memory usage and allocations over time). Would you be interested in trying it out when the branch is ready?

@e-dard What I noticed while trying to simulate the workload for this issue was a very high number of Get() requests failing the capacity check https://github.com/influxdata/influxdb/blob/master/pkg/pool/bytes.go#L28
	if cap(c) < sz {
		return make([]byte, sz)
	}

There were 200-400 calls to Bytes.Get() per second. Half of those requests were for small buffers of various sizes of less than 300k. The other half were for a single size of 1048576 bytes. In a very short period of time buffers in the pool channel were essentially randomly sized resulting in a lot of reallocations when the capacity check failed.
Looking back at the sync.Pool implementation from September there was similar logic. My guess is the problem was more about discarding these pooled buffers when the capacity check fails rather than a GC emptying the pool.  Maintaining a few pools of specific sized buffers removed this thrashing and the allocations went way down. Actually the total memory in all the pools went down quite a bit as well.
I've been busy this week and haven't been able to simplify my test procedure. I've looked at stress and stress/v2 but this workload is rather specific and I think it will be easier to just write a simple program to generate the load.
Let me know when your new branch is ready, I'm happy to test it.

@e-dard Here is the latest version of my experiment pools of specific sizes.
https://github.com/allenpetersen/influxdb/commit/b662d7532eafc02148d3b68d60343401ab71fd5c

@e-dard, @allenpetersen , reducing pool size with my patch solved memory issues for us, but if you want that we test something, I am available.

@jwilder, after I changed shard group duration, number of shards is decreasing little by little every day in last two weeks. Now, sudden crashes of influxdb are not happening so often.
It's quite possible that when thousands of these 24 hours shards expire, that influxdb will be not be crashing anymore.

Upgrade to influx 1.2.0-rc1 fixed the memory leak issue we were having. We've also dropped ~250 subscriptions which brought the number of goroutines down to a reasonable level.
However, Influx still crashes after 90-180 minutes of uptime and it seems it's not related to usage (write queries vs mixed queries).

@rubycut Has stability improved since lowering the number of shards?

@jwilder , we still have crashes, we are running 1.2.0-rc1, my colleague @weshmashian is running tests and trying various stuff, number of shards decreased significantly, since we are running 14 day shard groups since mid Dec, but we still have crashes, they usually crash after few hours, the longest period we were able to run it without crash is 48 hours.
@weshmashian can provide details.

We're actually running three versions - 1.1.0, 1.2.0-rc1 and 1.2.0. So far rc1 has had no crashes in past three days. We're trying to get the same behavior on 1.2.0 (matching configs and using the same dataset), but so far it was not successful.
We've also started getting the following panic on one 1.2.0-rc1:

goroutine 62183 [running]:
panic(0x9cd1e0, 0xc6b6936eb0)
        /home/influx/.gvm/gos/go1.7.4/src/runtime/panic.go:500 +0x1a1
github.com/influxdata/influxdb/tsdb/engine/tsm1.BlockCount(0x0, 0x0, 0x0, 0x8)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/encoding.go:224 +0x315
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*tsmKeyIterator).combine(0xc5b67aca00, 0x0, 0xa763a0, 0x1, 0xc7b9cbfbc0)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:1165 +0x6eb
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*tsmKeyIterator).merge(0xc5b67aca00)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:1101 +0x100
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*tsmKeyIterator).Next(0xc5b67aca00, 0xc813bb36ea)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:1068 +0x2bd
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Compactor).write(0xc5ae0d8b40, 0xc5bb7f1db0, 0x47, 0xe2c620, 0xc5b67aca00, 0x0, 0x0)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:774 +0x29b
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Compactor).writeNewFiles(0xc5ae0d8b40, 0x22f, 0x6, 0xe2c620, 0xc5b67aca00, 0xe2c620, 0xc5b67aca00, 0x0, 0x0, 0xc5ca243bf8)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:728 +0x284
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Compactor).compact(0xc5ae0d8b40, 0xba8400, 0xc5bb7f5300, 0x2, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:654 +0x52a
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Compactor).CompactFull(0xc5ae0d8b40, 0xc5bb7f5300, 0x2, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:672 +0x18e
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*compactionStrategy).compactGroup.func1(0xc5b4dcefc0, 0xc5bb7f5300, 0x2, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:1072 +0x15d
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*compactionStrategy).compactGroup(0xc5b4dcefc0, 0x0)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:1074 +0x47d
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*compactionStrategy).Apply.func1(0xc5b7551f80, 0xc5b4dcefc0, 0x0)
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:1047 +0x5d
created by github.com/influxdata/influxdb/tsdb/engine/tsm1.(*compactionStrategy).Apply
        /home/influx/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:1048 +0xcc

@weshmashian how often does that panic occur? Has it happened in the final 1.2.0  release?

@e-dard it happened on final 1.2.0 as well:
panic: count of short block: got 0, exp 1

goroutine 53530 [running]:
panic(0x9d12c0, 0xc6ad599740)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/influxdata/influxdb/tsdb/engine/tsm1.BlockCount(0x0, 0x0, 0x0, 0x8)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/encoding.go:224 +0x315
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*tsmKeyIterator).combine(0xc4a7675b00, 0x0, 0xa7a980, 0x1, 0xc7086c8c00)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:1165 +0x6eb
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*tsmKeyIterator).merge(0xc4a7675b00)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:1101 +0x100
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*tsmKeyIterator).Next(0xc4a7675b00, 0xc613bb36ea)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:1068 +0x2bd
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Compactor).write(0xc5183ba050, 0xc57fbdbdb0, 0x47, 0xe30720, 0xc4a7675b00, 0x0, 0x0)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:774 +0x29b
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Compactor).writeNewFiles(0xc5183ba050, 0x22f, 0x6, 0xe30720, 0xc4a7675b00, 0xe30720, 0xc4a7675b00, 0x0, 0x0, 0xc57cba1bf8)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:728 +0x284
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Compactor).compact(0xc5183ba050, 0xbacc00, 0xc570c61aa0, 0x2, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:654 +0x52a
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*Compactor).CompactFull(0xc5183ba050, 0xc570c61aa0, 0x2, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/compact.go:672 +0x18e
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*compactionStrategy).compactGroup.func1(0xc56eba0930, 0xc570c61aa0, 0x2, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:1072 +0x15d
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*compactionStrategy).compactGroup(0xc56eba0930, 0x0)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:1074 +0x47d
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*compactionStrategy).Apply.func1(0xc57cac3380, 0xc56eba0930, 0x0)
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:1047 +0x5d
created by github.com/influxdata/influxdb/tsdb/engine/tsm1.(*compactionStrategy).Apply
        /root/go/src/github.com/influxdata/influxdb/tsdb/engine/tsm1/engine.go:1048 +0xcc
[I] 2017-01-27T08:27:13Z InfluxDB starting, version 1.2.0, branch master, commit b7bb7e8359642b6e071735b50ae41f5eb343fd42

I've synced known good datadir and started up rc1 on it. It's not panicking any more, but it's stil too early to tell if it's going to crash.
Updated panic in previous comment as I only now realized it was missing the first line.

@weshmashian thanks. We need to open a new issue for this panic.

Should be fixed via #8348

My influx version  is 1.5.2-1
I read this whole thread and only understood to change the duration of shards , but it is no help.
My influx instance goes down every 1 hour or so. and this has started happening just 2-3 weeks before.
I have 35 databases . Retention policy of 1 month to each and shard duration is 2 weeks.
Attached some files for details
uname.txt
diagnostics.txt
iostat.txt
shards.txt
stats.txt


Make the Zebra logo fit in a standard 80 character terminal width

What happened?
I expected to see this happen:
Like zcashd, Zebra's default config should fit in a standard 80x24 character terminal.
Instead, this happened:

What were you doing when the issue happened?
Ran command zebrad on PR #6945, which is going to merge to main soon.
Zebra logs
Thank you for running a mainnet zebrad 1.0.0 node!
You're helping to strengthen the network and contributing to a social good :)
2023-06-27T03:21:05.970176Z  INFO zebrad::components::tracing::component: started tracing component filter="info" TRACING_STATIC_MAX_LEVEL=LevelFilter::INFO LOG_STATIC_MAX_LEVEL=Info
2023-06-27T03:21:05.970255Z  INFO zebrad::application: Diagnostic Metadata:
version: 1.0.0
Zcash network: Mainnet
state version: 25
features: default,release_max_level_info
branch: main
git commit: 3a96056
commit timestamp: 2023-06-26T23:11:57.000000000Z
target triple: aarch64-apple-darwin
rust compiler: 1.70.0
rust release date: 2023-05-31
optimization level: 3
debug checks: false
2023-06-27T03:21:05.970265Z  INFO zebrad::application: loaded zebrad config config_path=None config=ZebradConfig { consensus: Config { checkpoint_sync: true, debug_skip_parameter_preload: false }, metrics: Config { endpoint_addr: None }, network: Config { listen_addr: <IP_ADDRESS>:8233, network: Mainnet, initial_mainnet_peers: {"dnsseed.z.cash:8233", "dnsseed.str4d.xyz:8233", "mainnet.seeder.zfnd.org:8233", "mainnet.is.yolo.money:8233"}, initial_testnet_peers: {"dnsseed.testnet.z.cash:18233", "testnet.seeder.zfnd.org:18233", "testnet.is.yolo.money:18233"}, cache_dir: IsEnabled(true), peerset_initial_target_size: 25, crawl_new_peer_interval: 61s, max_connections_per_ip: 1 }, state: Config { cache_dir: "/Users/hyper/Library/Caches/zebra", ephemeral: false, debug_stop_at_height: None, delete_old_database: true }, tracing: Config { use_color: true, force_use_color: false, filter: None, buffer_limit: 128000, endpoint_addr: None, flamegraph: None, log_file: None, use_journald: false }, sync: Config { download_concurrency_limit: 50, checkpoint_verify_concurrency_limit: 1000, full_verify_concurrency_limit: 20, parallel_cpu_threads: 0 }, mempool: Config { tx_cost_limit: 80000000, eviction_memory_time: 3600s, debug_enable_at_height: None }, rpc: Config { listen_addr: None, parallel_cpu_threads: 1, debug_force_finished_sync: false } }

Zebra Version
Commit 3a96056 (1.0.0 + PR #6945)
Which operating systems does the issue happen on?

[X] Linux
[X] macOS
[ ] Windows
[ ] Other OS

OS details
Darwin machine-name 22.3.0 Darwin Kernel Version 22.3.0: Thu Jan  5 20:48:54 PST 2023; root:xnu-8792.81.2~2/RELEASE_ARM64_T6000 arm64
Additional information
Suggested fixes:

[ ] We can make the terminal images a little smaller
[ ] It might also help to move the heart one row down, currently it looks slightly higher than the circle (this is a visual trick due to its shape)

Something weird also happens in the GitHub Actions logs, but we're forcing colour anyway there, so it might not be worth fixing:
https://github.com/ZcashFoundation/zebra/actions/runs/5386324293/jobs/9776624309?pr=7077#step:4:176

That seems a quirk of how GitHub renders the log, the raw log is fine.
I was also wondering why the logo is being shown at all, since that only happens if stderr is a TTY. I think that's because we're running docker with the -t flag. But not sure if it's worth tinkering with that just to fix this.


Unhandle ApolloError@<IP_ADDRESS>:8081

i trying to use react native android with react-apollo, but this error.
on IOS, this not happen.

Hey, thanks for reporting this issue!
It looks like your description is missing some necessary information. Can you please add all the details specified in the template? This is necessary for people to be able to understand and reproduce the issue being reported.
I am going to close this, but feel free to open a new issue with the additional information provided. Thanks!

@hramos here is my project
https://github.com/lyquocnam/react-native-demo
please help, im so confuse with this @@

@lyquocnam did you resolve this? I'm having the same issue now

i abandon this project so long @JakeDawkins, react-native update many after that.


fix(antdv): variable.less not loaded when sets root-entry-name to variable

  css: {
    preprocessorOptions: {
      less: {
        javascriptEnabled: true,
        modifyVars: {
          'root-entry-name': 'variable'
        }
      }
    }
  },

Specifying root-entry-name as variable does not take effect.
ant-design-vue/${lib}/${styleDir}/style/index.js always loads default.less instead of following root-entry-name changes,
so we need to specify load less

Hi, is there any progress?

No. I don't use Antdv and I need someone else to review it.


splash cancel confirm() auto

splash cancel confirm() auto ,how to change it

Please, use StackOverflow to ask this type of questions.


Constantly need to restart Core.js

I just got my first project running with HAP-NodeJS. I'm using GarageDoorOpener_Accessory.js and everything works well... HOWEVER, even though my .JS file is running constantly (No errors) and works as expected, if I leave HomeKit for awhile (15 minutes or so) I am told my device has "no response" so I SSH into my pi, and restart Core.js
Is this a bug? I've tried running Core.js in forever, as well as straight node. Would it be a good idea to just write a script to kill the script and restart it every 15 minutes?
I'm running on a RasPi B+ so I don't want to tax it too hard as the power isn't really there.
Thanks!

Start you HAP-NodeJS at the terminal in wait Error, cover not just wait for the terminal !
I sometimes do and help me )

I'm honestly not real sure what to take away from that other than start in terminal and wait for an error. I do not receive any errors, the communication just appears to cease, and then come back randomly. From what I'm reading it could have to do with mDNS.

@pairughdocks You can start HAP-NodeJS in debug mode with DEBUG=* node Core.js. Even if HAP-NodeJS doesn't throw an error it may print something useful in debug logs.

@pairughdocks what type of raspberry pi are you using and more importantly what sort of power supply are you using?

I have a similar problem, HAPNodeJs part start without problems after a few hours crashes, if I try to relaunch Core.js seems to start with no problems but the accessories already associated with still do not respond, the only way is to restart the raspberry and It seems to fix this for another couple of hours except the return of the new problem.
I have a raspberry pi B (1) with a more than adequate power supply, also because the same setup worked for months without any problem, then after a node update began to appear similar problems, then I formatted everything and reinstalled from scratch to solve, but at the fifth installation from scratch I am again with HAPNodeJs that crashes.
node v 4.2.1
HAPNodeJs git cloned yesterday

same here. any idea to solve this problem?

@Supersimo88 @zenz how are you connecting to the network?  Cable or wifi?  Some wifi dongles can cause this problem.

@jat80 Hi, I'm using cable to connect my RPi3 to the network.

What I did is changed the startup from init.d to systemd. That way it will automatically restart if the node stops responding. I assume that the init.d command would run the node as long as it could, but couldn't tell if the node 'sleeps', because when i use systemctl to check the init.d: it says tht the service is running, yet there are no nodes or services attached to the service.
What works for me is to make a systemd by:
sudo nano /etc/systemd/system/homekit.service
And then type:
[Unit]
Description=Node.js HomeKit Server
After=syslog.target network-online.target
Then run
sudo systemctl daemon-reload
sudo systemctl enable home
[Service]
Type=simple
User=Root
ExecStart=/usr/local/bin/node /home/pi/HAP-NodeJS/Core.js (or BridgedCore.js or CameraCore.js)
Restart=on-failure
RestartSec=10
KillMode=process
[Install]
WantedBy=multi-user.target

sudo systemctl enable homekit.service
sudo systemctl start homekit.service
To check you can use sudo systemctl status homekit.service
I need to re-add the accessories, but after that it becomes stable and i don't need to restart it if the node 'sleeps'
This maybe isnt the best solution, but at least it should help from making you restart every now and then

What I did is changed the startup from init.d to systemd. That way it will automatically restart if the node stops responding. I assume that the init.d command would run the node as long as it could, but couldn't tell if the node 'sleeps', because when i use systemctl to check the init.d: it says tht the service is running, yet there are no nodes or services attached to the service.
What works for me is to make a systemd by:

sudo nano /etc/systemd/system/homekit.service
And then type:
[Unit]

Description=Node.js HomeKit Server

After=syslog.target network-online.target
[Service]

Type=simple
User=Root
ExecStart=/usr/local/bin/node /home/pi/HAP-NodeJS/Core.js (or BridgedCore.js or CameraCore.js); whichever youre using right now)
Restart=on-failure

RestartSec=10

KillMode=process
[Install]

WantedBy=multi-user.target
Then use:
sudo systemctl daemon-reload
sudo systemctl enable homekit.service
sudo systemctl start homekit.service
To monitor the service:
sudo systemctl status homekit.service

The stale bot seems to be bugged, gonna close it from hand as the issue seems stale.


Azure Event Grid - Extend 3 Minute Retry

Library name and version
Microsoft.Azure.Functions.Worker.Extensions.EventGrid 3.4.2
Query/Question
I have a simple Azure Event Grid Subscription that's fired when a blob container is hit. If my Azure Function doesn't respond it 3 minutes, it attempts to retry.
So I'm in a position where my first Azure function is still running (about a 5-6 minute process) yet another transaction gets sent in. So it ends up doubling my transactions that are created.
How can I extend the 3 minute window for the Event Grid to retry?
Azure Functions have a runtime of up to 10 minutes before they timeout, so there has to be a way to do this. Thanks.
Environment
No response

It doesn't appear that the retry timing is configurable based on this service doc. Tagging this as a service issue for confirmation.

Hi @aherrick.   Based on Josh's analysis, the retry behavior that you're asking about is controlled by the Azure Functions infrastructure.   The Azure SDK extensions package has no insight nor influence into these.    Unfortunately, the Azure Functions team does not monitor this repository nor respond to issues here.
In order to make sure that the right folks to assist have visibility, I've transferred this over to the repository where the Azure Functions .NET worker is maintained as #2819.

Apologies, @aherrick.   I incorrectly read this as an ask on the Functions-level retries failures when what you're actually asking about is retry behavior of the Event Grid service.   Neither the Functions infrastructure nor Azure SDK client have insight into nor influence over service behavior.   This is not something that the maintainers of the Azure SDK can assist with.
Unfortunately, the Event Grid service team does not monitor issues in our repository nor offer support from here.  To ensure that the right team has visibility and can help, your best path forward for would be to open an Azure support request or inquire on the Microsoft Q&A site.
Again, our apologies for the mis-classification and confusion with the initial triage.


[#111504612] Fix service link on status list

https://www.pivotaltracker.com/story/show/111504612

Looks good to me :+1:


Document add-to-app init sequence

For instance, when is the VM created, when the Isolate created. When is the entrypoint run. When is the widget tree created if runApp is run in the entrypoint. When is MediaQuery.of(context).size non-empty.

Also document which parts can be repeatedly run and which only happen once per X

According to Matt: this is a requirement of Dart isolates. We should just describe it.


[video_player] unable to play m3u8 links on iOS device

[video_player] I have noticed some of the links are not working on iOS(real) devices. example m3u8 link
https://sfux-ext.sfux.info/hls/chapter/105/1588724110/1588724110.m3u8 it works well on both devices android and iOS.
I have tried some m3u8 links which are not working on iOS real devices but works on android devices, please find the below example links.
https://5421175365ea3.streamlock.net/live/smil:switch.smil/playlist.m3u8
<EMAIL_ADDRESS>How can we resolve it ?

Closing this as duplicate of https://github.com/flutter/flutter/issues/48670


Wrong path set when uploading picture using blue "Upload" button

Describe the issue that you're seeing. Any Loom videos or screenshots usually help a lot!
Wrong path is set when uploading picture using blue "Upload" button. Basically I have next.js app. I added tina, I added following config to upload image:
        {
            type: "string",
            name: "image1",
            label: "Image #1",
            required: true,
            ui: {
                component: "image",
            },
        },

When I click blue button to Upload media, expected behavior would be that media is uploaded to particular sub directory. Currently it's always uploaded to the root of public/ directory.
I also tried following:
        {
            type: "string",
            name: "image1",
            label: "Image #1",
            required: true,
            ui: {
                component: "image",
                parse: (fullSrc: any) =>
                    `${
                        typeof fullSrc === "string"
                            ? fullSrc
                            : `/img/projects/${fullSrc.filename}`
                    }`,
            },
            previewSrc: (fullSrc: string) => fullSrc.replace("/public", ""),
        },

But it didn't help either.
Reproduction
https://donthave.com
Steps to reproduce

Install tina
Add image field
Add a sub-directory to Media dir
Try to upload picture to the subdirectory

System Info
Brake
Node 16
Next.js 13

Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug.

@MattCCC This sounds like a good use case for mediaRoot. Have you tried that?
If you publicFolder is "public" and mediaRoot is "img/projects" your images will be uploaded to public/img/projects.

If media root does not fit your use case and you are looking for this to be configurable on a per field bases you can try using uploadDir. (It would be better to use mediaRoot if all your images are in /img/projects )
        {
            type: "image",
            name: "image1",
            label: "Image #1",
            required: true,
            ui: {
                  uploadDir: ()=>"/img/projects"
            },
        },

One other note:
Why are you doing?
        {
           //...
            type: "string",
            ui: {
                 component: 'image',
            },
        },

This will cause issues if you are using Git backed media. It could be the cause of your current issue.
Maybe try?
        {
           //...
            type: "image",
        },

cc @MattCCC  @PothieuG

I'm facing the same issue.
When using uploadDir, my file always ends up at the root of my public folder, despite having a folder structure in TinaCMS that suggests I'm uploading to the right place.


Khalil/signatures

[ ] Closes #xxxx (Replace xxxx with the GitHub issue number)
[ ] Tests added and passed if fixing a bug or adding a new feature
[ ] All code checks passed.
[ ] Added type annotations to new arguments/methods/functions.
[ ] Added an entry in the latest docs/release_notes/index.md file if fixing a bug or adding a new feature.
[ ] If the changes are patches for a version, I have added the on-merge: backport to x.x.x label.

Apologies this was a mistake from a forked repository.


[BUG] Export to PDF with no english dates not working

Describe the bug
Export to PDF with no english dates not working.
To Reproduce
Steps to reproduce the behavior:

Change language theme (in french, for exemple)
Export to PDF.

Expected behavior
Dates should be in french.
Screenshots

Desktop (please complete the following information):

OS: Linux
Browser: Firefox
Version: v3.2.6

Able to reproduce this issue, working on a fix now :)

Thank you!

Hello, as of v3.8.4, this issue is still happening, the steps are the same, OS is Linux, Browser is Firefox
In-editor:

Exported PDF:


add a maintenance indicator when backend is offline

Issue is with src/index.js which await checkLoggedIn(), which configures the session store

session system not included in new API, unneccesary


Reproduction for issue #371

#371

Superseded by https://github.com/com-lihaoyi/upickle/pull/443


Scam Account Submission

Duplicate Submissions

[X] Yes, I checked that the account name is not currently in the list
[X] I read the wiki explaining each different categories and examples before submitting

(Required) Spam Comment Direct Link
username "susanna bruemmer" https://www.youtube.com/channel/UCx5jMH06BUC9VD_vE1NeO4w
(Optional) Screenshot of comments referencing the scam account

(Required) List of the scam account names
priscilla dearmin-turner

The thread doesn't have an explicit Telegram or Whatsapp account it refers to. It tells people to google her name, and if you do that it pops up a website for a financial advisor https://priscillaturner.com/#rs-about which says she's a registered US broker but when I check on the FINRA website she isn't registered any longer (she stopped being an investment advisor and broker in April 2022) https://brokercheck.finra.org/individual/summary/2209187


balena-image: install only required i915 firmware

Requires: https://github.com/balena-os/meta-balena/pull/2240
Change-type: patch
Changelog-entry: Install only required i915 firmware
Signed-off-by: Joseph Kogut<EMAIL_ADDRESS>

@resin-jenkins retest this please

@resin-jenkins retest this please


[GHSA-r4ph-mx67-x58p] Shopware database password is leaked to an unauthenticated users

Updates

Affected products

Comments
The composer package name shopware/shopware refers to Shopware 5 and is a totally different system. See https://github.com/shopware5/shopware/blob/5.7/composer.json#L2
We just renamed the GitHub repository name from shopware/platform to shopware/shopware  a while ago.
This urgently needs to be fixed, as it spreads misinformation about a wrong security issue on a project that is not affected

Hi @mitelg, we appreciate this information. Just to confirm, what should the package name be updated to?

hey @CallmeMari
the affected packages are still in there. platform and core

@CallmeMari any news on this? unfortunately the misinformation already spread a lot...

Hey @mitelg, I'm so sorry this didn't get handled in a timely manner. I've pulled shopware/shopware as an affected product and added an explicit note to the advisory about shopware 5. I think I've found the correct fix commit as well in
https://github.com/shopware/core/commit/3c759bbeeda8b59d6f3792f75a0ac28cffeef8c6
Does that look right to you?

hey @darakian
thanks for merging and adding the note. I see on packagist, that the latest Shopware 5 releases are not longer marked as affected by this :+1:
Yes, that should be the fix, addressing this issue

I see on packagist, that the latest Shopware 5 releases are not longer marked as affected by this 👍

👀
Do you know if packagist is pulling from our database for those markings? News to me if so.

TIL. I had no idea they were ingesting from us. Neat!


percySnapshot + percyCSS does not work as expected

Hello!
I have been trying to use percyCSS option as outlined in the documentation, and I cannot get it to work.
Here is an example:
// This is a schematic example with QUnit and Ember
test('An amazing test', async function(assert) {
  await visit('/some-url');
  await percySnapshot(assert, {
    percyCSS: `
      .an-existing-css-class {
        display: none !important;
      }
    `
  });
});

I have tried specifying the same CSS in Percy configuration and that did not work:
// .percy.js
module.exports = {
  version: 2,
  snapshot: {
    widths: [1440],
    // match testing container
    minHeight: 900,
    percyCSS: `
      .an-existing-css-class {
        display: none !important;
      }
    `
  },
  discovery: {
    allowedHostnames: [],
    // https://git.io/JZLF4
    // Increased asset discovery timeout to help with font loading
    networkIdleTimeout: 250,
  },
  static: {
    baseUrl: '/',
    files: '**/*.{html,htm}',
    ignore: '',
  },
  upload: {
    files: '**/*.{png,jpg,jpeg}',
    ignore: '',
  },
};

I have tried using the media query, like so and that did not work:
@media only percy {
  .an-existing-css-class {
    display: none !important;
  }
}

The only way I got it to work is via a new class that I have to apply to every element of the DOM I want hidden which is subpar:
@media only percy {
  .hide-in-percy {
    display: none !important;
  }
}

I feel like I'm missing something obvious but cannot seem to see it, unfortunately.
I am using the latest published versions of both @percy/percy-ember & @percy/cli.

Hey @twokul! The best way to debug this if you give a snapshot ID where this CSS is expected to work. Usually when we see this not work it's due to specificity (but having the snapshot will lend more info as to what's going on)

@Robdel12 👋 Here is a link to the build & screenshot. The CSS class is .nav-date-chooser (trying to hide it.)
I was somewhat surprised that percyCSS worked in one case but did not in others 😄 I have to be missing something obvious 😄

Thanks for that link 😃 I see in a snapshot below the linked one it does have Percy specific CSS applied:
 This would be the snapshot percyCSS option passed (not the @media only percy approach). That does look like it works there.
But the linked snapshot doesn't have any Percy specific CSS file (hm, why? 🤨) It seems like these are being passed as per-snapshot options and .percy.js config might not be captured?. Can you run with --verbose with that CSS in the config file? it should log out the config that's being used for that build. And that CSS will be applied to each captured snapshot too.

Here is another test run with the following config:
module.exports = {
  version: 2,
  snapshot: {
    widths: [1440],
    // match testing container
    minHeight: 900,
    percyCSS: `
      div[data-test-nav-date-chooser], .report-page-thumbnail canvas {
        display: none !important;
      }
    `,
  },
};

div[data-test-nav-date-chooser] elements are hidden as expected; .report-page-thumbnail canvas are not.

It seems like these are being passed as per-snapshot options and .percy.js config might not be captured?

I do think the config is captured because some of the styles are applied from it. I could not get the per-snapshot option to work at all 🤔
Output with --verbose:
➜  percy exec -v -- ember test --filter='[visual acceptance]'
[percy:config] Found config file: .percy.js (0ms)
[percy:config] Using config:
{
  version: 2,
  snapshot: {
    widths: [
      1440
    ],
    minHeight: 900,
    percyCSS: '\n' +
      '      div[data-test-nav-date-chooser], .report-page-thumbnail canvas {\n' +
      '        display: none !important;\n' +
      '      }\n' +
      '    '
  },
  discovery: {
    allowedHostnames: [],
    networkIdleTimeout: 500
  },
  static: {
    baseUrl: '/',
    files: '**/*.{html,htm}',
    ignore: ''
  },
  upload: {
    files: '**/*.{png,jpg,jpeg}',
    ignore: ''
  }
} (16ms)
[percy:client] Creating a new build... (13ms)
[percy:core:install] Successfully downloaded Chromium 812851 (64823ms)
[percy:core] Percy has started! (2234ms)
[percy:cli:exec] Running "ember test --filter=[visual acceptance]" (0ms)

In any case, let me know if I can provide any other info 💪

That looks to be working:

All the snapshots I've downloaded from that build have the Percy CSS present, so that's good news 😃
From here it looks like it's a selector issue. In the Panel Controls | Transaction Center renders as expected snapshot, the CSS is present but there's no selector on the page with div[data-test-nav-date-chooser].

A little tricky tip for .report-page-thumbnail canvas -- that wont work because we're not rendering canvas elements in Percy's browsers. Canvas doesn't carry any state in the DOM, so we serialize it into an image. You'll want report-page-thumbnail img for that one to hide the canvas el (which is really an image). We copy over attrs/classes from the canvas element, so if you target by selector rather than tag it would work too (looks like there's a .report-thumbnail-canvas class on the canvas element).

Alright! 🚀
So this config seems to work as expected, link to the build:
module.exports = {
  version: 2,
  snapshot: {
    widths: [1440],
    // match testing container
    minHeight: 900,
    percyCSS: '.report-thumbnail-canvas, div[data-test-nav-date-chooser] { display: none !important; }',
  },
  discovery: {
    allowedHostnames: [],
    // https://git.io/JZLF4
    // Increased asset discovery timeout to help with font loading
    networkIdleTimeout: 500,
  },
  static: {
    baseUrl: '/',
    files: '**/*.{html,htm}',
    ignore: '',
  },
  upload: {
    files: '**/*.{png,jpg,jpeg}',
    ignore: '',
  },
};

@Robdel12 Do you have any idea why the following does not work?
// This is a schematic example with QUnit and Ember
test('An amazing test', async function(assert) {
  await visit('/some-url');
  await percySnapshot(assert, {
    percyCSS: `
      .an-existing-css-class {
        display: none !important;
      }
    `
  });
});


client.servers error

Summary
len(client.servers) doesnt get servers added to if in the same session
Reproduction Steps
use len(client.servers) and invite it (your bot) to a server and it wont update
Minimal Reproducible Code
No response
Expected Results
show
Actual Results
didnt update members or servers
Checklist

[X] I have searched the open issues for duplicates.
[X] I have shown the entire traceback, if possible.
[X] I have removed my token from display, if visible.

Additional Context
No response

yes there's already an open issue, check #18


fix: move fragment error handling to utils instead

Summary
Move fragments error handling into utils file

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


App crashes when Using the Impeller rendering backend

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce

macOS 13.5.2 (22G91)
XCode Version 15.0 (15A240d)
Simulator Version 15.0 (1015.2)
iOS version iPhone 8 Plus iOS 16.4 (20E247)
Flutter (Channel stable, 3.13.4, on macOS 13.5.2 22G91 darwin-arm64, locale
zh-Hans-CN)

and  flutter run
Expected results
open the app
Actual results
App crashes  , dont see anything
Code sample
no
Screenshots or Video
no
Logs
Logs

................

[   +9 ms] executing: /usr/bin/arch -arm64e xcrun simctl launch D616D730-1708-4207-9C4B-37D1FD90A943 com.yanse.peidui --enable-dart-profiling --enable-checked-mode --verify-entry-points
[ +105 ms] com.yanse.peidui: 5397
[        ] Waiting for VM Service port to be available...
[+1140 ms] [VERBOSE-2:FlutterDarwinContextMetalImpeller.mm(37)] Using the Impeller rendering backend.

................

Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.13.4, on macOS 13.5.2 22G91 darwin-arm64, locale
    zh-Hans-CN)
    • Flutter version 3.13.4 on channel stable at
      /opt/homebrew/Caskroom/flutter/3.13.4/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 367f9ea16b (8 days ago), 2023-09-12 23:27:53 -0500
    • Engine revision 9064459a8b
    • Dart version 3.1.2
    • DevTools version 2.25.0

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/toquery/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: /Users/toquery/Applications/Android
      Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      17.0.6+0-17.0.6b829.9-10027231)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A240d
    • CocoaPods version 1.12.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.3)
    • Android Studio at /Users/toquery/Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      17.0.6+0-17.0.6b829.9-10027231)

[✓] IntelliJ IDEA Ultimate Edition (version 2023.2.2)
    • IntelliJ at /Users/toquery/Applications/IntelliJ IDEA Ultimate.app
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.82.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.72.0

[!] Proxy Configuration
    • HTTP_PROXY is set
    ! NO_PROXY is not set

[✓] Connected device (3 available)

.....

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

Same issue here.
XCode version: 15.0
Flutter version: 3.13.4
iOS version: 17.0, 16.4 & 15.5 tested

We can't actually help find or fix the crash if you provide no details. Please file a new issue and follow the issue template.

The same issue occurs after upgrading to XCode 15.
This error occurs on my iOS 16.3.1 and other lower version devices, but the simulator of iOS 17 does not have this problem.

I had the same issue, its due to goole_mobile_ads package. Add below lines in info.plist
GADApplicationIdentifier
ca-app-pub-xxxxxxxxxxxxxxxxxx

Same for me using xcode 15 & flutter 3.13.5
Launching lib/main.dart on Ahmed’s iPhone in debug mode...
Automatically signing iOS for device deployment using specified development team in Xcode project: [REDUCTED]
Xcode build done.                                           41.0s
(lldb) 2023-09-25 12:44:01.048624+0300 [dev] dkilo walk[452:24041] [VERBOSE-2:FlutterDarwinContextMetalImpeller.mm(37)] Using the Impeller rendering backend.
2023-09-25 12:44:01.066695+0300 [dev] dkilo walk[452:24041] Warning: Unable to create restoration in progress marker file
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x0000000000000000
error: memory read failed for 0x0
Target 0: ([dev] dkilo walk) stopped.
Error launching application on Ahmed’s iPhone.
Exited

I solved my problem temporarily. The error I reported here was caused by connectivity_plus. I temporarily removed connectivity_plus. I don’t know if other people also have errors due to this reason. At least that’s the case for me. You can refer to here.

I believe all this is due to some packages, try removing packages one by one to see which one is causing the issue.
Method used by me -

create a new project and all the packages from your current project
run the new project, I bet it will again show the same error.
If yes, then keep commenting packages, untill you find the package with the issue.

then check documentation of that package and see where is your configuration missing for that specific package.

I solved my problem temporarily. The error I reported here was caused by connectivity_plus. I temporarily removed connectivity_plus. I don’t know if other people also have errors due to this reason. At least that’s the case for me. You can refer to here.

This worked for me also. Thank you

I had exactly the same problem. I removed connectivity_plus and now it works... Strange... Everything worked fine a few weeks ago.... I guess before some updates...

The Xcode 15 release supports on-device debugging in iOS 12 and later so you just have to update the iOS deployment target to 12.0+

Install the latest connectivity_plus plugin.

The Xcode 15 release supports on-device debugging in iOS 12 and later so you just have to update the iOS deployment target to 12.0+

This works on me. Thanks!

I turned off the "Debug executable" in Product -> Edit Scheme -> Info tab, and it worked.

See the log while reporting
Most of time have plugin issue

I have the same issue but was solved updating connectivity_plus. Thanks guys.

I have the same issue but was solved updating connectivity_plus. Thanks guys.

I can't remove connectivity_plus due to dependency from amplify_api.  I can also not upgrade connectivity_plus to 5.0.1 for the same reason.  Any advice?

I'm already targeting iOS 12.0+
I need to resolve the connectivity_plus version issue

adding the code to my Podfile worked, except I had to target version 13.0 and reflect same in my XCode project

Open Xcode -> Pods.
Find connectivity_plus.
Increase the Minimum Deployments to 12.0

After upgrading to connectivity_plus 5.0.1 (build 10/14/2023) it resolved my issue. This was indirectly caused by upgrading to Sonoma 14.0 / Xcode 15.0.1 / Android Studio Giraffe 2022.3.1 Patch 2 and pushing to iOS 16.7.2.

Same issue. how to resolve it...

I solved my problem temporarily. The error I reported here was caused by connectivity_plus. I temporarily removed connectivity_plus. I don’t know if other people also have errors due to this reason. At least that’s the case for me. You can refer to here.
Thank you so much 👏


Correct cp pipeline and rerun

@gwaybio
Here is the partial PR for NF1. I was able to rerun the pipelines with the correction for analyzing the whole image features (the orig_nuclei issue was handled in previous PR). I was able to get the All CellProfiler pipelines for Plate 1 and 2 ran for everything (except heatmaps for Plate 2).
The common pattern I am seeing is that very pipeline is giving different results.

@jenna-tomkinson - I pulled this branch and I'm currently working through this PR. It's tough to figure out what's going on! There are a ton of files, and it's unclear to me how they've been generated.
We had talked about creating a separate benchmarking repository. I'm wondering if it's a better option to move the multi-pipeline benchmarking to a separate repo and close this PR in this repo. This repo can focus on the core CP pipeline we've been using. What do you think? I hesitate to merge this not being able to track provenance of figures.

@gwaybio They are all generated using the pipelines originally made. I agree there are a ton of files.
What I think would be best is that I will make a slideshow with all the figures for the core CP pipeline so that we can look them over. As for the repos, I am thinking we might make two new repos at this point because this repo wouldn't be good to have as the main CP pipeline since there is a lot in it that is not apart of the CP pipeline (mainly cause of DP). This would be good to have a meeting over.

Sounds good. Let's discuss next week.

@jenna-tomkinson - it seems the plates are more similar than maybe we initially thought - see recent commits

@gwaybio
I am planning on creating a new commit in this PR with the following changes (essentially refactoring):

Edit CellProfiler analysis pipelines:

Remove the extra MeasureGranularity module (learned that it does both images and objects)
Remove and change MeasureObjectNeightbors to measure adjacent neighbors (was set to a specific distance)

Change structure of running the CellProfiler pipelines to using a notebook and the command line (similar to what is done in the CFReT project) and rerun all methods with the updated pipelines.
Update the extraction of single cells to have a utility function that will call the SingleCell class, merge, normalize, and feature selection so that all methods can be performed in one notebook.
Remove all extra figures that were created in the analysis module except for those for the all CellProfiler method and those created by @gwaybio

@gwaybio
This PR has been refactored and is ready for review!
To make this easier, I recommend reviewing per commit as each commit is pretty small unless it deletes files. See below for a detailed list of each commit.

daf19af: Create functions to run each method through CellProfiler and rename the SQLite file to reflect the method used (e.g., CellProfiler IC + Cellpose segmentation = cellprofiler_cellpose). As well, there are two notebooks, one for each plate, that uses these functions.
882612d: In this commit, I removed all old SQLite files from previous run and added the new SQLite files that were acquired using the new method implemented in the previous commit.
8a2ef5b: The CellProfiler pipelines using CP segmentation and Cellpose segmentation have been updated to reflect the changes I stated in the previous comment.
Note: Ignore commits 899ebbf and b212cf5 as one contains an version of a file that is updated in another commit and the other only deletes files.
baa41bd: This commit contains major README changes to reflect the three new notebooks that run all CP and DP methods for each plate. There is a file with functions to run Pycytominer (essentially Cytosnake 🤣) which makes it easier to run multiple methods in one notebook.
6f5295e: Add all new csv.gz files with extracted single cells from each method.
893609f: This last commit goes into the analysis module and remove all figures from running the notebooks with any other method other than the All CellProfiler method or DeepProfiler with plate 1. This should revert all notebooks back to how they are currently in the repo.

I apologize that this needed such a refactor, but I think this will be easier to work with and is much cleaner.

@roshankern Thank you for the review! The next PRs will be short I promise (gotta make mistakes to be able to learn :smile:).
@gwaybio I will now merge this PR and it should be good to go for Cameron to use and test NF1 analysis with.


Perhaps integrate multi-user support

I don't know what you exactly mean with "multi-user support". But attached you'll find a patch, that enables your library to be used with different google-accounts without touching .config.json.
It's done by supplying a json-object to GetAll().
This way, you can pull several google-accounts in just one script.
multiuser.patch.txt

This has been resolved by https://github.com/rapidwebltd/php-google-contacts-v3-api/pull/38.


pythonPackages.xapian: init -> 1.4.8

Motivation for this change
Python bindings for Xapian, which is a dependency for a larger project I'm packaging.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

also, try and use the pname as folder name.

Am having some weird issues with the GitHub interface... can't respond to the questions anymore...

@leenaars any progress on the PR? GitHub is doing weird things in their UI recently, it should be fine to leave a comment here (where you quote the review comments) if you have questions or want to discuss about these :)

@leenaars are your github issues resolved to a point you can continue on this?


No Backtesting/importing Data possible in UI

After I figured out how to use the stable version and was quite smooth with backtesting I tried to get the ui working.
1.) downloaded the develop zip
2.) installed dependencies (npm)
3.) started ui
So far everything worked fine.
Problem # 1 importing data doesn't work. I can start the import and it also takes time until it finished importing. After the import is finished (successful according to Web ui) no data can be found and no history folder was created.
Problem # 2 if I start backtesting (imported history data from stable version) I get the graph but no buy and sell indicators and results are also not calculated:

the console delivers also strange output (several times number 2, happens only with CCI Strategy):

anything I missed out? latest MacOS
Thanks!

Oddly I am getting the NaN issue as well. On the debug-advice as well which seems odd.

Hey, same here for problem 1, tried different exchanges, but dataset are invisible
Debian, with Gekko v0.4.4 and Gekko UI v0.1.2

@Zep18
does backtesting work for you?

My bad! Should be fixed now. Either git pull or redownload the zip.

thanks for fixing!
backtesting works great. Importer still not working (at least for me). Is the importer supposed to work?

It's supposed to work like this. If it is not, could you describe the problem in a new issue?

getting this error in console after a very short period of the backtester starting in ui:
<-- POST /api/backtest
xxx POST /api/backtest 500 7,778ms -
Error: non-error thrown: Child process has died.
at Object.onerror (/Users/freefall/gekkoinstalls/gekko-develop/node_modules/koa/lib/context.js:105:40)
at process._tickCallback (internal/process/next_tick.js:103:7)
This is with any date range (changed or otherwise, any sized dataset and any strategy;rsi, talib macd and custom talib.

@thegamecat please open a new issue since this is not related to this one.


Error on validate with error message

Hi,
I'm having problems with the errors array on validate. Rails returns:
ArgumentError: wrong number of arguments (0 for 1)
I'm using like this (exact as the example):
class Setting < ActiveRecord::Base
  serialize :data_json, JSON

  validates :data_json, json: {
    schema: Rails.root.join('config', 'my_schema.json_schema').to_s,
    message: ->(errors) { errors }
  }
end

I'm using Rails 3.2.22. Could you help me? Thanks.

Can you specify the complete backtrace so we can see exactly where the ArgumentError is triggered? Thank you!

This is the backtrace.
ArgumentError: wrong number of arguments (0 for 1)
	from /Users/bruno.ferraro/work/app/models/setting.rb:8:in `block in <class:Setting>'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activemodel-3.2.22/lib/active_model/errors.rb:361:in `call'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activemodel-3.2.22/lib/active_model/errors.rb:361:in `normalize_message'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activemodel-3.2.22/lib/active_model/errors.rb:234:in `add'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord_json_validator-0.1.2/lib/active_record/json_validator/validator.rb:28:in `validate_each'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activemodel-3.2.22/lib/active_model/validator.rb:153:in `block in validate'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activemodel-3.2.22/lib/active_model/validator.rb:150:in `each'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activemodel-3.2.22/lib/active_model/validator.rb:150:in `validate'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activesupport-3.2.22/lib/active_support/callbacks.rb:310:in `_callback_before_3691'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activesupport-3.2.22/lib/active_support/callbacks.rb:407:in `_run__2955623584968405592__validate__1070666409970389912__callbacks'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activesupport-3.2.22/lib/active_support/callbacks.rb:405:in `__run_callback'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activesupport-3.2.22/lib/active_support/callbacks.rb:385:in `_run_validate_callbacks'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activesupport-3.2.22/lib/active_support/callbacks.rb:81:in `run_callbacks'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activemodel-3.2.22/lib/active_model/validations.rb:228:in `run_validations!'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activemodel-3.2.22/lib/active_model/validations/callbacks.rb:53:in `block in run_validations!'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activesupport-3.2.22/lib/active_support/callbacks.rb:403:in `_run__2955623584968405592__validation__1070666409970389912__callbacks'
... 7 levels...
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord-3.2.22/lib/active_record/validations.rb:50:in `save'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord-3.2.22/lib/active_record/attribute_methods/dirty.rb:22:in `save'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord-3.2.22/lib/active_record/transactions.rb:259:in `block (2 levels) in save'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord-3.2.22/lib/active_record/transactions.rb:313:in `block in with_transaction_returning_status'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord-3.2.22/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord-3.2.22/lib/active_record/transactions.rb:208:in `transaction'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord-3.2.22/lib/active_record/transactions.rb:311:in `with_transaction_returning_status'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord-3.2.22/lib/active_record/transactions.rb:259:in `block in save'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord-3.2.22/lib/active_record/transactions.rb:270:in `rollback_active_record_state!'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/activerecord-3.2.22/lib/active_record/transactions.rb:258:in `save'
	from (irb):8
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/railties-3.2.22/lib/rails/commands/console.rb:47:in `start'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/railties-3.2.22/lib/rails/commands/console.rb:8:in `start'
	from /Users/bruno.ferraro/.rvm/gems/ruby-2.0.0-p598@work/gems/railties-3.2.22/lib/rails/commands.rb:41:in `<top (required)>'
```

Since the error is happening in app/models/setting.rb:8, could you paste the exact content (or the first 8 lines) of your app/models/setting.rb file?

The line 8 is that
  validates :data_json, json: {
    schema: Rails.root.join('config', 'my_schema.json_schema').to_s,
    message: ->(errors) { errors }    # line 8
  }
````

Now I note that I'm using the version 0.1.2 because I have some limitations on activerecord  dependencies.

Oh! We currently do not support older versions like 0.1.2. I’m pretty sure passing a Proc to  message option was not supported back then…


someTypeRelatedToType now passes isIntersectionConstituent

The quick check for intersection sources doesn't pass isIntersectionConstituent, which incorrectly causes excess property checking to happen on intersection constituents.
In this example, the quick check happens when checking g(CC), and incorrectly finds that CP is not assignable to { children?: boolean } even though the latter is part of CP & { children?: boolean }. The result is the cached, which breaks the assignability check on the next line: <CC {...(null as CP) }/>.
This is a 3.6 regression, but the example is so complex that I'm not sure how hard it is to reproduce.
interface F<P> {
    (props: P & { children?: boolean }): void;
    propTypes: { [K in keyof P]: null extends P ? K : K };
}
declare function g(C: F<unknown>): string;
export function wu<CP extends { o: object }>(CC: F<CP>) {
    class WU {
        m() {
            g(CC)
            return <CC {...(null as unknown as CP)} />;
        }
    }
}

Fixes #33133
Edit: Added commentary from the issue:
The basic problem is that the flag isIntersectionConstituent, which is used to exempt intersection constituents from common-property checks ("weak types"), isn't threaded through one particular intersection call in assignability checking. I missed it when threading that flag through more calls in 3.6 (https://github.com/microsoft/TypeScript/pull/32582), and my new assertion in overload error reporting caught the mistake. It's quite likely that this assert would have fired a lot more before #32582.

@typescript-bot cherry-pick this to release-3.6


Upscaling glitches

sometimes some tiles do not get rendered correctly.

again, same spot

Hey, thanks for taking the time to submit an issue.
Can you please share the config/settings you have used for upscaling here?
Any other contextual information that would help our team reproduce the issue would be appreciated, e.g. what GPU do you have? Has this always happened or only on certain builds? etc.
Thanks again :)

I used default settings, deliberate model to generate the picture. I don't remember the buld number. GPU is a RX 7900 XTX 24GB. I used the stable diffusion x4 model for upscaling. Default setting with no prompts


Menu content won't scroll unless main content is tall enough

Ionic version:  (check one with "x")
[x] 2.x
I'm submitting a ...  (check one with "x")
[x] bug report
Current behavior:
In Safari, the scrolling of the menu is tied to the content. If the main content isn't taller than the view, then the menu won't scroll even though its content is taller than the view. When you add content to the main view, scrolling in the menu will work.
Expected behavior:
Scrolling in the menu should always work if the content is long enough.
Steps to reproduce:
Try scrolling in the menu, then toggle the segment and try again.
http://plnkr.co/edit/YpOJBp?p=preview
Related code:
n/a

Other information:
Safari Version 10.0.2 (Haven't tested on an iPhone)
Ionic info: (run ionic info from a terminal/cmd prompt and paste output below):
Cordova CLI: 6.4.0
Ionic Framework Version: 2.0.0-rc.5
Ionic CLI Version: 2.2.1
Ionic App Lib Version: 2.2.0
Ionic App Scripts Version: 1.0.0
ios-deploy version: 1.9.0
ios-sim version: 5.0.13
OS: macOS Sierra
Node Version: v6.9.4
Xcode version: Xcode 8.2.1 Build version 8C1002

Works fine for me in Chrome... do you mean test it on a device?

It's specifically a Safari bug.

Does it happen when you test on device?
On Jan 16, 2017, 10:20 AM -0500, Patrick McDonald<EMAIL_ADDRESS>wrote:

It's specifically a Safari bug.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (https://github.com/driftyco/ionic/issues/10039#issuecomment-272889461), or mute the thread (https://github.com/notifications/unsubscribe-auth/AEPIEhvKmHGGZTtfAu51ra1WVcbf3G6Pks5rS4q9gaJpZM4Lj7ug).

Duplicate of #10017 ;)


Fix deprecations

Questions
Answers

Description?
Fix deprecations

Type?
refactor

BC breaks?
no

Deprecations?
yes

Fixed ticket?
Relative to PrestaShop/PrestaShop#24609 and PrestaShop/PrestaShop#31216

Sponsor company
@PrestaShopCorp

How to test?
The module works well on a PrestaShop 8.1.0.

@florine2623 Thanks for your feedback
@nicosomb & @Hlavtox I have fixed the error in 501a1c0.

Blocking because of the discussion around modules versioning.

@kpodemski Could you please give the Github Discussion / Github Issue ? Or is it a private discussion ?

@Progi1984 it's a discussion with other maintainers, there will be an ADR

@Progi1984 it's a private discussion with other maintainers, there will be an ADR

Perfect. Thanks

Blocked by PrestaShop/ADR#32

Module ready to be released.

After this is merged no?

Yes @Hlavtox


Unable to deploy Groups to dbt using the provider

When trying to use the resource: resource "dbt_cloud_group" it is giving error:
Error: POST url: https:///api/v3/accounts//groups/, status: 404, body: {"status":{"code":404,"is_success":false,"user_message":"The requested resource was not found. Please check that you have the proper permissions. If you are seeing this in error, please contact support!","developer_message":""},"data":null}

Hi!
Could you please share a sanitised version for the config of the group?
And is the error message the full one you are getting back from the provider?
Or did you remove your account number etc.. (the URL just looks odd)

I did not add actual url so its like placeholders as I cannot share actual url
Maria Chaudry
Data Operations Engineer
Mobile:<PHONE_NUMBER>5
Email<EMAIL_ADDRESS>www.three.co.ukhttp://www.three.co.uk
Life Needs a Big Network
[cid:ff609bad-a5fc-4033-bcf1-10a3f2084ea2][cid:bf61995f-f96b-4654-9496-125062dfc7f0]

From: Benoit Perigaud @.>
Sent: 31 October 2023 9:16 AM
To: dbt-labs/terraform-provider-dbtcloud @.>
Cc: Maria Chaudry @.>; Author @.>
Subject: Re: [dbt-labs/terraform-provider-dbtcloud] Unable to deploy Groups to dbt using the provider (Issue #207)
You don't often get email from @.*** Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
CAUTION! External Email.
Hi!
Could you please share a sanitised version for the config of the group?
And is the error message the full one you are getting back from the provider?
Or did you remove your account number etc.. (the URL just looks odd)
—
Reply to this email directly, view it on GitHubhttps://github.com/dbt-labs/terraform-provider-dbtcloud/issues/207#issuecomment-1786810452, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A23ZTKPSFIY4IFSE44I3ROLYCC6WXAVCNFSM6AAAAAA6XKRLISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBWHAYTANBVGI.
You are receiving this because you authored the thread.Message ID: @.***>
This e-mail message (including any attachment) is intended only for the personal use of the recipient(s) named above. This message is confidential and may be legally privileged.  If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message.
Any views or opinions expressed in this message are those of the author only. Furthermore, this message (including any attachment) does not create any legally binding rights or obligations whatsoever, which may only be created by the exchange of hard copy documents signed by a duly authorized representative of Hutchison 3G UK Limited. Hutchison 3G UK Limited is a company registered in England and Wales with company number 3885486. Registered Office: 450 Longwater Avenue, Green Park, Reading, Berkshire, RG2 6GF.

OK, thanks for clarifying.
Would it be possible to share the group config though? You can change any sensitive information but it will help me to know what fields are being used.

This is snippet of apply
module.<module_name>.module.dbt-cloud-group.dbt_cloud_group.dbt-cloud-group["group_developer"] will be created

resource "dbt_cloud_group" "dbt-cloud-group" {

assign_by_default  = false

id                 = (known after apply)

is_active          = true

name               = ""

sso_mapping_groups = [

"",
]

group_permissions {

all_projects   = false
permission_set = "developer"
project_id     =
}
}

Plan: 1 to add, 0 to change, 0 to destroy.
module.<module_name>.dbt_cloud_group.dbt-cloud-group["group_developer"]: Creating...
Error: POST url: https:///api/v3/accounts//groups/, status: 404, body: {"status":{"code":404,"is_success":false,"user_message":"The requested resource was not found. Please check that you have the proper permissions. If you are seeing this in error, please contact support!","developer_message":""},"data":null}
with module.<module_name>.module.dbt-cloud-group.dbt_cloud_group.dbt-cloud-group["group_developer"],
on .terraform/modules/<module_name>/terraform-modules/dbt/module-group/module-group.tf line 11, in resource "dbt_cloud_group" "dbt-cloud-group":
11: resource "dbt_cloud_group" "dbt-cloud-group" {
and provider I am using is:
"GtheSheep/dbt-cloud"
Maria Chaudry
Data Operations Engineer
Mobile:<PHONE_NUMBER>5
Email<EMAIL_ADDRESS>www.three.co.ukhttp://www.three.co.uk
Life Needs a Big Network
[cid:cdedf0d7-ba65-4e9d-9c61-06aab377bdb3][cid:84a7f307-0baf-46b3-ae81-50a2f67a2377]

From: Benoit Perigaud @.>
Sent: 31 October 2023 9:21 AM
To: dbt-labs/terraform-provider-dbtcloud @.>
Cc: Maria Chaudry @.>; Author @.>
Subject: Re: [dbt-labs/terraform-provider-dbtcloud] Unable to deploy Groups to dbt using the provider (Issue #207)
CAUTION! External Email.
OK, thanks for clarifying.
Would it be possible to share the group config though? You can change any sensitive information but it will help me to know what fields are being used.
—
Reply to this email directly, view it on GitHubhttps://github.com/dbt-labs/terraform-provider-dbtcloud/issues/207#issuecomment-1786817903, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A23ZTKOLZNFXUWWPYM2HVX3YCC7IFAVCNFSM6AAAAAA6XKRLISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBWHAYTOOJQGM.
You are receiving this because you authored the thread.Message ID: @.***>
This e-mail message (including any attachment) is intended only for the personal use of the recipient(s) named above. This message is confidential and may be legally privileged.  If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message.
Any views or opinions expressed in this message are those of the author only. Furthermore, this message (including any attachment) does not create any legally binding rights or obligations whatsoever, which may only be created by the exchange of hard copy documents signed by a duly authorized representative of Hutchison 3G UK Limited. Hutchison 3G UK Limited is a company registered in England and Wales with company number 3885486. Registered Office: 450 Longwater Avenue, Green Park, Reading, Berkshire, RG2 6GF.

I will try to replicate it in the latest version of the provider, but please be aware that the version you are using which is no longer maintained and the new provider is dbt-labs/dbtcloud.
There is some info here on how to switch from the previous one to the new one.
If there is actually a bug, we could fix it in dbt-labs/dbtcloud but there is no way to fix/update GtheSheep/dbt-cloud anymore.

oh okay so we should use this provider thanks I will try with that in that case
Maria Chaudry
Data Operations Engineer
Mobile:<PHONE_NUMBER>5
Email<EMAIL_ADDRESS>www.three.co.ukhttp://www.three.co.uk
Life Needs a Big Network
[cid:290f5e59-ff57-473d-bd6c-d7785c1debde][cid:001671ae-cc77-4de6-b1c2-00a418c1328a]

From: Benoit Perigaud @.>
Sent: 31 October 2023 9:52 AM
To: dbt-labs/terraform-provider-dbtcloud @.>
Cc: Maria Chaudry @.>; Author @.>
Subject: Re: [dbt-labs/terraform-provider-dbtcloud] Unable to deploy Groups to dbt using the provider (Issue #207)
CAUTION! External Email.
I will try to replicate it in the latest version of the provider, but please be aware that the version you are using which is no longer maintained and the new provider is dbt-labs/dbtcloudhttps://registry.terraform.io/providers/dbt-labs/dbtcloud/latest.
There is some info herehttps://github.com/dbt-labs/terraform-provider-dbtcloud/blob/main/UPGRADING_PROVIDER.md on how to switch from the previous one to the new one.
If there is actually a bug, we could fix it in dbt-labs/dbtcloud but there is no way to fix/update GtheSheep/dbt-cloud anymore.
—
Reply to this email directly, view it on GitHubhttps://github.com/dbt-labs/terraform-provider-dbtcloud/issues/207#issuecomment-1786872985, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A23ZTKPHGCI6LPGVFFKP3F3YCDC5JAVCNFSM6AAAAAA6XKRLISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBWHA3TEOJYGU.
You are receiving this because you authored the thread.Message ID: @.***>
This e-mail message (including any attachment) is intended only for the personal use of the recipient(s) named above. This message is confidential and may be legally privileged.  If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message.
Any views or opinions expressed in this message are those of the author only. Furthermore, this message (including any attachment) does not create any legally binding rights or obligations whatsoever, which may only be created by the exchange of hard copy documents signed by a duly authorized representative of Hutchison 3G UK Limited. Hutchison 3G UK Limited is a company registered in England and Wales with company number 3885486. Registered Office: 450 Longwater Avenue, Green Park, Reading, Berkshire, RG2 6GF.

@marychaudry , by the way, just be aware that when you reply to the GH comments by email it adds some personal details. I have been editing your last messages to remove them but I just wanted to let you know.

okay Ill delete the above messages didn't realize thanks for above :)

Let me know how it goes with the "new" provider. And if there is the same issue, I would just need to get the config that you shared before to try to replicate and fix it.

Sure let me put it here: This is snippet of apply
module.<module_name>.module.dbt-cloud-group.dbt_cloud_group.dbt-cloud-group["group_developer"] will be created

resource "dbt_cloud_group" "dbt-cloud-group" {

assign_by_default  = false

id                 = (known after apply)

is_active          = true

name               = ""

sso_mapping_groups = [

"",
]

group_permissions {

all_projects   = false
permission_set = "developer"
project_id     =
}
}

Plan: 1 to add, 0 to change, 0 to destroy.
module.<module_name>.dbt_cloud_group.dbt-cloud-group["group_developer"]: Creating...
Error: POST url: https:///api/v3/accounts//groups/, status: 404, body: {"status":{"code":404,"is_success":false,"user_message":"The requested resource was not found. Please check that you have the proper permissions. If you are seeing this in error, please contact support!","developer_message":""},"data":null}
with module.<module_name>.module.dbt-cloud-group.dbt_cloud_group.dbt-cloud-group["group_developer"],
on .terraform/modules/<module_name>/terraform-modules/dbt/module-group/module-group.tf line 11, in resource "dbt_cloud_group" "dbt-cloud-group":
11: resource "dbt_cloud_group" "dbt-cloud-group" {

Hi I have tried using the provider:
required_providers {
dbtcloud = {
source = "dbt-labs/dbtcloud"
version = "0.2.12"
}
but it is still not able to apply the groups:
module.dbt_bds_bureau_project.module.dbt-cloud-group.dbtcloud_group.dbt-cloud-group["group_developer"] will be created
resource "dbtcloud_group" "dbt-cloud-group" {
assign_by_default  = false
id                 = (known after apply)
is_active          = true
name               = "_dbt_nonprod_deployer"
sso_mapping_groups = [
"<>",
]
group_permissions {
all_projects   = false
permission_set = "developer"
project_id     = <prj_id>
}
}

Thanks, I will try on my side then.

I tried the same config on my side and it is working fine.
@marychaudry , could you please raise a support ticket from dbt Cloud about this issue? I guess that you are on Single Tenant, no?
In that case, when getting in touch with support, please tell them that your account is on ST and you are getting a 404 on one of the v3 API endpoints.

Yes we are single tenant so maybe it is because of that
Maria Chaudry
Data Operations Engineer
Mobile:<PHONE_NUMBER>5
Email<EMAIL_ADDRESS>www.three.co.ukhttp://www.three.co.uk
Life Needs a Big Network
[cid:59c5dc31-3c3d-4a24-b78e-0c93c55af5a0][cid:58806643-e18d-446e-9ca9-bf76b327a47d]

From: Benoit Perigaud @.>
Sent: 31 October 2023 1:24 PM
To: dbt-labs/terraform-provider-dbtcloud @.>
Cc: Maria Chaudry @.>; Mention @.>
Subject: Re: [dbt-labs/terraform-provider-dbtcloud] Unable to deploy Groups to dbt using the provider (Issue #207)
CAUTION! External Email.
I tried the same config on my side and it is working fine.
@marychaudryhttps://github.com/marychaudry , could you please raise a support ticket from dbt Cloud about this issue? I guess that you are on Single Tenant, no?
In that case, when getting in touch with support, please tell them that your account is on ST and you are getting a 404 on one of the v3 API endpoints.
—
Reply to this email directly, view it on GitHubhttps://github.com/dbt-labs/terraform-provider-dbtcloud/issues/207#issuecomment-1787213033, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A23ZTKPVUN56KQ2ISY2IQG3YCD3ZBAVCNFSM6AAAAAA6XKRLISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBXGIYTGMBTGM.
You are receiving this because you were mentioned.Message ID: @.***>
This e-mail message (including any attachment) is intended only for the personal use of the recipient(s) named above. This message is confidential and may be legally privileged.  If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message.
Any views or opinions expressed in this message are those of the author only. Furthermore, this message (including any attachment) does not create any legally binding rights or obligations whatsoever, which may only be created by the exchange of hard copy documents signed by a duly authorized representative of Hutchison 3G UK Limited. Hutchison 3G UK Limited is a company registered in England and Wales with company number 3885486. Registered Office: 450 Longwater Avenue, Green Park, Reading, Berkshire, RG2 6GF.

Hi @marychaudry. Did you end raising a ticket with support? If so, do you have a number I could check?

Your request (56913) has been updated.

Thinking about it a bit more now, what token to you use for connecting to Terraform?

a personal token?
a service token? and if so, what permissions does this token have?

I am wondering if this is not related to the token not having the access required

It is service token, I will check what permission token has

A service token requires either of these roles in order to create dbt Cloud user groups:

Account Admin
Security Admin

I believe @marychaudry was able to resolve the problem after creating a token with one of the roles mentioned above so it was indeed a permission issue (or lack thereof).

Thanks @jeremyyeo !
I wish we returned a 401 instead of a 404...

Fwiw - some services return 404 when you are unauthorized to access a resource in order to not provide any information at all (no information) vs providing some information that a resource exist but you are unauthorized (more information that before).
GitHub does this.