Exception: Value cannot be null After upgrading to Abp V1.0.0

I got the below Exception after upgrading to Version Abp V1.0.0
Handling.AbpApiExceptionFilterAttribute - Value cannot be null.
Parameter name: value
System.ArgumentNullException: Value cannot be null.
Parameter name: value
   at System.Security.Claims.Claim..ctor(String type, String value, String valueType, String issuer, String originalIssuer, ClaimsIdentity subject, String propertyKey, String propertyValue)
   at System.Security.Claims.Claim..ctor(String type, String value)
   at Microsoft.AspNet.Identity.ClaimsIdentityFactory`2.<CreateAsync>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Abp.Authorization.Users.AbpUserManager`2.<CreateIdentityAsync>d__40.MoveNext() in D:\Halil\GitHub\module-zero\src\Abp.Zero\Authorization\Users\AbpUserManager.cs:line 323
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Abp.Authorization.AbpLogInManager`3.<CreateLoginResultAsync>d__18.MoveNext() in D:\Halil\GitHub\module-zero\src\Abp.Zero\Authorization\AbpLoginManager.cs:line 216
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at Abp.Authorization.AbpLogInManager`3.<LoginAsyncInternal>d__17.MoveNext() in D:\Halil\GitHub\module-zero\src\Abp.Zero\Authorization\AbpLoginManager.cs:line 194
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Abp.Authorization.AbpLogInManager`3.<LoginAsync>d__16.MoveNext() in D:\Halil\GitHub\module-zero\src\Abp.Zero\Authorization\AbpLoginManager.cs:line 0
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Abp.Threading.InternalAsyncHelper.<AwaitTaskWithPostActionAndFinallyAndGetResult>d__5`1.MoveNext() in D:\Halil\GitHub\aspnetboilerplate\src\Abp\Threading\InternalAsyncHelper.cs:line 120
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at HrPayroll.Reports.Web.Controllers.AccountController.<GetLoginResultAsync>d__8.MoveNext() in D:\src\HrPayrollV2\src\HrPayroll.Reports.Web\Controllers\AccountController.cs:line 61
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at HrPayroll.Reports.Web.Controllers.AccountController.<Authenticate>d__7.MoveNext() in D:\src\HrPayrollV2\src\HrPayroll.Reports.Web\Controllers\AccountController.cs:line 44
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Threading.Tasks.TaskHelpersExtensions.<CastToObject>d__3`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Abp.WebApi.Uow.AbpApiUowFilter.<ExecuteActionFilterAsync>d__5.MoveNext() in D:\Halil\GitHub\aspnetboilerplate\src\Abp.Web.Api\WebApi\Uow\AbpApiUowFilter.cs:line 53
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Abp.WebApi.Validation.AbpApiValidationFilter.<ExecuteActionFilterAsync>d__5.MoveNext() in D:\Halil\GitHub\aspnetboilerplate\src\Abp.Web.Api\WebApi\Validation\AbpApiValidationFilter.cs:line 49
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Abp.WebApi.Auditing.AbpApiAuditFilter.<ExecuteActionFilterAsync>d__4.MoveNext() in D:\Halil\GitHub\aspnetboilerplate\src\Abp.Web.Api\WebApi\Auditing\AbpApiAuditFilter.cs:line 47
--- End of stack trace from previous location where exception was thrown ---
   at Abp.WebApi.Auditing.AbpApiAuditFilter.<ExecuteActionFilterAsync>d__4.MoveNext() in D:\Halil\GitHub\aspnetboilerplate\src\Abp.Web.Api\WebApi\Auditing\AbpApiAuditFilter.cs:line 53
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Abp.WebApi.Security.AntiForgery.AbpAntiForgeryApiFilter.<ExecuteAuthorizationFilterAsync>d__10.MoveNext() in D:\Halil\GitHub\aspnetboilerplate\src\Abp.Web.Api\WebApi\Security\AntiForgery\AbpAntiForgeryApiFilter.cs:line 59
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Abp.WebApi.Authorization.AbpApiAuthorizeFilter.<ExecuteAuthorizationFilterAsync>d__7.MoveNext() in D:\Halil\GitHub\aspnetboilerplate\src\Abp.Web.Api\WebApi\Authorization\AbpApiAuthorizeFilter.cs:line 61
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.Http.Controllers.AuthenticationFilterResult.<ExecuteAsync>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.Http.Controllers.ExceptionFilterResult.<ExecuteAsync>d__0.MoveNext()

I'm trying to do authentication through the Api Controller.

Run UPDATE AbpUsers SET SecurityStamp = NEWID() SQL command in your database. This is written in release notes: https://github.com/aspnetboilerplate/module-zero/releases/tag/v<IP_ADDRESS>

You are right it was my mistake.


Missing file name in goheader linter message

When the header is missing the Golang goheader linter does not report the filename in which the header is missing.
Example: https://github.com/ethersphere/bee/actions/runs/3657344894/jobs/6180907778

maybe it would be more suitable to open this issue on repository for this linter

I recommend checking first to see if there is a new version that maybe fixes this, or if there is another similar linter (that doesn't have this problem) that we could use instead of this one.


os/signal: test flaky on darwin-amd64

The os/signal test seems to time out fairly frequently on the darwin-amd64-race builder.
It's not obvious to me whether the test is deadlocked or just slow.
Example: https://build.golang.org/log/7c20aa477d782f38c6184e7f8bce05c9648b57b3
panic: test timed out after 3m0s

goroutine 20 [running]:
testing.(*M).startAlarm.func1()
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:1332 +0x11c
created by time.goFunc
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/time/sleep.go:169 +0x52

goroutine 1 [chan receive]:
testing.(*T).Run(0xc0000c0000, 0x42154f9, 0x9, 0x421e888, 0x1)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:917 +0x68a
testing.runTests.func1(0xc0000c0000)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:1157 +0xa7
testing.tRunner(0xc0000c0000, 0xc000046db0)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:865 +0x163
testing.runTests(0xc00000e060, 0x435ace0, 0xb, 0xb, 0x0)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:1155 +0x522
testing.(*M).Run(0xc0000ba000, 0x0)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:1072 +0x2ea
main.main()
	_testmain.go:64 +0x21f

goroutine 4 [syscall]:
os/signal.signal_recv(0x4247580)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/sigqueue.go:139 +0x9f
os/signal.loop()
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_unix.go:23 +0x30
created by os/signal.init.0
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_unix.go:29 +0x4f

goroutine 10 [runnable]:
runtime.Gosched(...)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/proc.go:266
os/signal.signalWaitUntilIdle()
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/sigqueue.go:172 +0x31
os/signal.Stop(0xc00009c300)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal.go:196 +0x2f3
runtime.Goexit()
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/panic.go:503 +0xec
testing.(*common).FailNow(0xc0000c0300)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:609 +0x5b
testing.(*common).Fatalf(0xc0000c0300, 0x4218523, 0x16, 0xc0000e6d18, 0x1, 0x1)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:672 +0x9f
os/signal.waitSig(0xc0000c0300, 0xc00009c2a0, 0x4247580, 0x42436a8)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_test.go:32 +0x309
os/signal.testCancel(0xc0000c0300, 0xc00003b700)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_test.go:133 +0x1f9
os/signal.TestReset(0xc0000c0300)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_test.go:187 +0x3e
testing.tRunner(0xc0000c0300, 0x421e888)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:865 +0x163
created by testing.(*T).Run
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:916 +0x652

goroutine 8 [runnable]:
runtime.Gosched(...)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/proc.go:266
os/signal.signalWaitUntilIdle()
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/sigqueue.go:172 +0x31
os/signal.Stop(0xc00009c180)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal.go:196 +0x2f3
os/signal.TestStress.func1(0xc000022480, 0xc0000224e0)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_test.go:92 +0x194
created by os/signal.TestStress
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_test.go:79 +0xe1
FAIL	os/signal	180.028s

CC @ianlancetaylor for os/signal

In the stack trace two goroutines are stuck in this loop in signalWaitUntilIdle (in runtime/sigqueue.go):
	for atomic.Load(&sig.delivering) != 0 {
		Gosched()
	}

sig.delivering can only be non-zero while executing sigsend, also in runtime/sigqueue.go.  sigsend is invoked by the signal handler.  There is no code in sigsend that blocks, and sigsend always returns with sig.delivering unchanged.
So this seems to be impossible.  The failure presumably has something to do with the race detector, but I don't know why it would be Darwin specific.

@dvyukov for any ideas.

Some thoughts:

It could be another manifestation of the race in #20748.
Perhaps the fact that it's Darwin-specific has something to do with the interaction with libc. (Do we invoke sigaction via libc on Darwin now?) I seem to recall that TSAN tends to defer signal delivery until the next libc call (see #18717), so if we're hitting the TSAN hooks for signal delivery and then the test is idling in a way that doesn't ping back into libc, that could deadlock it.

Not just race, it turns out. @andybons notes that it's also here:
https://build.golang.org/log/65130fd6cf64710896cae0a569087f8fa8df66fc (darwin-amd64-10_14)

And that last one is on the Go 1.12 release branch.
@randall77, @ianlancetaylor, should this block the Go 1.12.2 release?

It's hard to believe that this is new in 1.12.2 compared to 1.12, so I don't see a reason to block the 1.12.2 release.

Just saw this on my pre-Mojave Mac as well. It's too bad the stack trace does not include any signal-handling thread stacks. It looks for all the world like sig.delivering is non-zero and it would be very nice to see where exactly the signal-handling thread is.
panic: test timed out after 9m0s

goroutine 24 [running]:
testing.(*M).startAlarm.func1()
	/Users/rsc/go/src/testing/testing.go:1380 +0xdf
created by time.goFunc
	/Users/rsc/go/src/time/sleep.go:169 +0x44

goroutine 1 [chan receive]:
testing.(*T).Run(0xc000152100, 0x4167a64, 0x9, 0x4170e60, 0x4078a01)
	/Users/rsc/go/src/testing/testing.go:964 +0x377
testing.runTests.func1(0xc0000fe000)
	/Users/rsc/go/src/testing/testing.go:1205 +0x78
testing.tRunner(0xc0000fe000, 0xc000054e30)
	/Users/rsc/go/src/testing/testing.go:912 +0xbf
testing.runTests(0xc0000d4020, 0x426fca0, 0xb, 0xb, 0x0)
	/Users/rsc/go/src/testing/testing.go:1203 +0x2a7
testing.(*M).Run(0xc0000fa000, 0x0)
	/Users/rsc/go/src/testing/testing.go:1120 +0x160
main.main()
	_testmain.go:64 +0x135

goroutine 34 [syscall]:
os/signal.signal_recv(0x41931e0)
	/Users/rsc/go/src/runtime/sigqueue.go:139 +0x9f
os/signal.loop()
	/Users/rsc/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
	/Users/rsc/go/src/os/signal/signal_unix.go:29 +0x41

goroutine 23 [runnable]:
runtime.Gosched(...)
	/Users/rsc/go/src/runtime/proc.go:269
os/signal.signalWaitUntilIdle()
	/Users/rsc/go/src/runtime/sigqueue.go:172 +0x30
os/signal.Stop(0xc0000be240)
	/Users/rsc/go/src/os/signal/signal.go:196 +0x18c
runtime.Goexit()
	/Users/rsc/go/src/runtime/panic.go:503 +0xec
testing.(*common).FailNow(0xc000152100)
	/Users/rsc/go/src/testing/testing.go:656 +0x39
testing.(*common).Fatalf(0xc000152100, 0x416ab68, 0x16, 0xc000043588, 0x1, 0x1)
	/Users/rsc/go/src/testing/testing.go:719 +0x90
os/signal.waitSig(0xc000152100, 0xc0000be1e0, 0x41931e0, 0x418f4e0)
	/Users/rsc/go/src/os/signal/signal_test.go:32 +0x247
os/signal.testCancel(0xc000152100, 0x2be993261bf00)
	/Users/rsc/go/src/os/signal/signal_test.go:133 +0x1ce
os/signal.TestReset(0xc000152100)
	/Users/rsc/go/src/os/signal/signal_test.go:187 +0x30
testing.tRunner(0xc000152100, 0x4170e60)
	/Users/rsc/go/src/testing/testing.go:912 +0xbf
created by testing.(*T).Run
	/Users/rsc/go/src/testing/testing.go:963 +0x350

goroutine 21 [runnable]:
runtime.Gosched(...)
	/Users/rsc/go/src/runtime/proc.go:269
os/signal.signalWaitUntilIdle()
	/Users/rsc/go/src/runtime/sigqueue.go:172 +0x30
os/signal.Stop(0xc000024120)
	/Users/rsc/go/src/os/signal/signal.go:196 +0x18c
os/signal.TestStress.func1(0xc000138120, 0xc000138180)
	/Users/rsc/go/src/os/signal/signal_test.go:92 +0x160
created by os/signal.TestStress
	/Users/rsc/go/src/os/signal/signal_test.go:79 +0xd3
FAIL	os/signal	540.197s

One on darwin-arm64-corellium (https://build.golang.org/log/89688609340e1b045e263677ed0bf9b0cdd84710):

panic: test timed out after 3m0s

goroutine 10 [running]:
testing.(*M).startAlarm.func1()
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/testing/testing.go:1382 +0xc0
created by time.goFunc
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/time/sleep.go:169 +0x38

goroutine 1 [chan receive]:
testing.(*T).Run(0x130112200, 0x10248ee96, 0x9, 0x1024981c0, 0x5ce80e01)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/testing/testing.go:961 +0x2b4
testing.runTests.func1(0x1300f4000)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/testing/testing.go:1207 +0x6c
testing.tRunner(0x1300f4000, 0x13003edf8)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/testing/testing.go:909 +0xa8
testing.runTests(0x1300b8060, 0x102596e20, 0xb, 0xb, 0x0)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/testing/testing.go:1205 +0x24c
testing.(*M).Run(0x1300e0000, 0x0)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/testing/testing.go:1122 +0x140
main.main()
	_testmain.go:66 +0x144

goroutine 19 [syscall]:
os/signal.signal_recv(0x1024bbc60)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/runtime/sigqueue.go:139 +0xb8
os/signal.loop()
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/os/signal/signal_unix.go:23 +0x18
created by os/signal.init.0
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/os/signal/signal_unix.go:29 +0x30

goroutine 9 [runnable]:
runtime.Gosched(...)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/runtime/proc.go:269
os/signal.signalWaitUntilIdle()
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/runtime/sigqueue.go:172 +0x2c
os/signal.Stop(0x130080360)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/os/signal/signal.go:196 +0x1a8
runtime.Goexit()
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/runtime/panic.go:503 +0xdc
testing.(*common).FailNow(0x130112200)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/testing/testing.go:653 +0x30
testing.(*common).Fatalf(0x130112200, 0x102491f08, 0x16, 0x13003dd78, 0x1, 0x1)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/testing/testing.go:716 +0x70
os/signal.waitSig(0x130112200, 0x130080300, 0x1024bbc60, 0x1024b7e80)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/os/signal/signal_test.go:32 +0x19c
os/signal.testCancel(0x130112200, 0x13003df00)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/os/signal/signal_test.go:133 +0x188
os/signal.TestReset(0x130112200)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/os/signal/signal_test.go:187 +0x24
testing.tRunner(0x130112200, 0x1024981c0)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/testing/testing.go:909 +0xa8
created by testing.(*T).Run
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/testing/testing.go:960 +0x298

goroutine 7 [runnable]:
runtime.Gosched(...)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/runtime/proc.go:269
os/signal.signalWaitUntilIdle()
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/runtime/sigqueue.go:172 +0x2c
os/signal.Stop(0x1300ca480)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/os/signal/signal.go:196 +0x1a8
os/signal.TestStress.func1(0x130128120, 0x130128180)
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/os/signal/signal_test.go:92 +0x110
created by os/signal.TestStress
	/tmp/workdir-host-darwin-arm64-corellium-ios/go/src/os/signal/signal_test.go:79 +0xd0
FAIL	os/signal	180.141s

darwin-amd64-10_12:

panic: test timed out after 3m0s

goroutine 21 [running]:
testing.(*M).startAlarm.func1()
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:1382 +0xdf
created by time.goFunc
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/time/sleep.go:169 +0x44

goroutine 1 [chan receive]:
testing.(*T).Run(0xc00013c100, 0x4164e26, 0x9, 0x416e1f8, 0x4077c01)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:961 +0x377
testing.runTests.func1(0xc0000f2000)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:1207 +0x78
testing.tRunner(0xc0000f2000, 0xc000046e30)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:909 +0xbf
testing.runTests(0xc0000d0020, 0x426ec60, 0xb, 0xb, 0x0)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:1205 +0x2a7
testing.(*M).Run(0xc0000e6000, 0x0)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:1122 +0x160
main.main()
	_testmain.go:66 +0x135

goroutine 34 [syscall]:
os/signal.signal_recv(0x41903a0)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/sigqueue.go:139 +0x9f
os/signal.loop()
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_unix.go:29 +0x41

goroutine 20 [runnable]:
runtime.Gosched(...)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/proc.go:269
os/signal.signalWaitUntilIdle()
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/sigqueue.go:172 +0x30
os/signal.Stop(0xc0000ae1e0)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal.go:196 +0x18c
runtime.Goexit()
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/panic.go:503 +0xec
testing.(*common).FailNow(0xc00013c100)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:653 +0x39
testing.(*common).Fatalf(0xc00013c100, 0x4167f1f, 0x16, 0xc00004bd88, 0x1, 0x1)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:716 +0x90
os/signal.waitSig(0xc00013c100, 0xc0000ae180, 0x41903a0, 0x418c628)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_test.go:32 +0x247
os/signal.testCancel(0xc00013c100, 0x5b15d2f4400)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_test.go:133 +0x1ce
os/signal.TestReset(0xc00013c100)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_test.go:187 +0x30
testing.tRunner(0xc00013c100, 0x416e1f8)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:909 +0xbf
created by testing.(*T).Run
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/testing/testing.go:960 +0x350

goroutine 5 [runnable]:
runtime.Gosched(...)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/proc.go:269
os/signal.signalWaitUntilIdle()
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/runtime/sigqueue.go:172 +0x30
os/signal.Stop(0xc0000b2180)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal.go:196 +0x18c
os/signal.TestStress.func1(0xc0000220c0, 0xc000022120)
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_test.go:92 +0x160
created by os/signal.TestStress
	/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir/go/src/os/signal/signal_test.go:79 +0xee
FAIL	os/signal	180.025s

Now that the builders are back up (#32449) and the nocgo builds are fixed (#31705), the flake rate for this test seems to have shot up.
https://build.golang.org/log/9f82044d48d9d2454b9f09dc29dee1b3555e3086
https://build.golang.org/log/22e8c4dbce68c1fd280faf88e20fa59581c93a48
https://build.golang.org/log/14a435ac4cb1c3707828d9523d7c7dde3ded139c
https://build.golang.org/log/f2d647807dea54014f010c5cbcb07c71458df3e0
https://build.golang.org/log/dfbce3d94ad1ed5d6fa3db4ede672ef2f3f3c265
https://build.golang.org/log/90f020c5fff16116505b4d52afe061c7c2e04cd9
https://build.golang.org/log/909199d4dee74aa617667ab83fca20ff56b3ea6b
https://build.golang.org/log/7d428b0cfbcab441070b6bb430f9f70a3411201c
https://build.golang.org/log/2885a1bbec67b815c975a65c45a4610ce177512d
https://build.golang.org/log/62b5c702e02c81c47e548e478dbab8dfd3d53890

This has been happening for a while.  The first occurrence seems to be on June 18, 2018:
https://build.golang.org/log/d464d075b04b100b96b7e9b7614755c02efd9dfa
The first occurrence that is not on the race builder is from July 13, 2018, but is on 386:
https://build.golang.org/log/5a14c8368922d5d3c4a19e4e7aff37111d916bd3
The first occurrence on amd64, not on the race builder, is July 18, 2018:
https://build.golang.org/log/0666f3b1dfa397938a4e93fe89afb97bdd2769e7
That is an interesting one, because it shows time.Sleep(10 * time.Millisecond) as sleeping for 3 minutes.  The next more typical occurrence on amd64, not on the race builder, is from August 20, 2018:
https://build.golang.org/log/924b174c273ad0f136081ef3d1d9751bada8253b
That shows the most common pattern: a goroutine started by TestStress is hanging waiting for a deferred call to Stop to complete, and the test TestReset is also hanging waiting for a deferred call to Stop to complete.  The deferred call to Stop from TestReset is occurring because TestReset has failed, timed out waiting for a SIGWINCH to be delivered.
June 2018, when the problems started happening, is when the runtime package was changing to move some operations from direct system calls to library calls.  E.g., https://golang.org/cl/118819, https://golang.org/cl/118736.  Notably https://golang.org/cl/117176 was committed on June 12, 2018: "runtime: use libc for signal functions on iOS".

Actually a possibly more relevant CL is https://golang.org/cl/116875, committed June 12, 2018: "runtime: use libc's signal functions on Darwin".

Through sheer luck I triggered the problem on a gomote.  The process appears to be burning CPU.  I attached to it using lldb and got this stack trace:
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff60d11f06 libsystem_kernel.dylib`__psynch_mutexwait + 10
    frame #1: 0x00007fff60dc8d52 libsystem_pthread.dylib`_pthread_mutex_firstfit_lock_wait + 96
    frame #2: 0x00007fff60dc64cd libsystem_pthread.dylib`_pthread_mutex_firstfit_lock_slow + 222
    frame #3: 0x000000000405f57c signal.test`runtime.pthread_mutex_lock_trampoline + 12
    frame #4: 0x000000000405cf8d signal.test`runtime.asmcgocall + 173
    frame #5: 0x000000000405f570 signal.test`runtime.pthread_mutex_init_trampoline + 32
    frame #6: 0x000000000404c909 signal.test`runtime.pthread_mutex_lock + 57
    frame #7: 0x000000000402b93a signal.test`runtime.semawakeup + 42
    frame #8: 0x000000000400b959 signal.test`runtime.notewakeup + 89
    frame #9: 0x0000000004044233 signal.test`runtime.sigsend + 275
    frame #10: 0x0000000004041e90 signal.test`runtime.sighandler + 288
    frame #11: 0x0000000004042f6c signal.test`runtime.sigtrampgo + 572
    frame #12: 0x000000000405f263 signal.test`runtime.sigtramp + 51
  * frame #13: 0x000000000402b93a signal.test`runtime.semawakeup + 42
    frame #14: 0x000000000400b959 signal.test`runtime.notewakeup + 89
    frame #15: 0x0000000004044233 signal.test`runtime.sigsend + 275
    frame #16: 0x0000000004041e90 signal.test`runtime.sighandler + 288
    frame #17: 0x0000000004042f6c signal.test`runtime.sigtrampgo + 572
    frame #18: 0x000000000405f263 signal.test`runtime.sigtramp + 51
    frame #19: 0x000000000400b959 signal.test`runtime.notewakeup + 89
    frame #20: 0x0000000004044233 signal.test`runtime.sigsend + 275
    frame #21: 0x0000000004041e90 signal.test`runtime.sighandler + 288
    frame #22: 0x0000000004042f6c signal.test`runtime.sigtrampgo + 572
    frame #23: 0x000000000405f263 signal.test`runtime.sigtramp + 51
    frame #24: 0x0000000004044233 signal.test`runtime.sigsend + 275
    frame #25: 0x0000000004041e90 signal.test`runtime.sighandler + 288
    frame #26: 0x0000000004042f6c signal.test`runtime.sigtrampgo + 572
    frame #27: 0x000000000405f263 signal.test`runtime.sigtramp + 51
    frame #28: 0x0000000004041e90 signal.test`runtime.sighandler + 288
    frame #29: 0x0000000004042f6c signal.test`runtime.sigtrampgo + 572
    frame #30: 0x0000000004042f6c signal.test`runtime.sigtrampgo + 572
    frame #31: 0x000000000405f263 signal.test`runtime.sigtramp + 51
    frame #32: 0x000000000405f263 signal.test`runtime.sigtramp + 51

It looks like when sigsend calls notewakeup it is triggering a signal.  Thus we never get out of sigsend and so sig.delivering really is always non-zero.  Continuing to investigate.

This C program triggers a SIGSEGV in a signal handler while SIGSEGV is blocked.  On normal Unix systems that causes the kernel to immediately kill the program: since the SIGSEGV cannot be delivered, nothing else can happen.  On macOS, however, it causes the program to hang while burning CPU.  So I think that explains the symptom: in some cases sigsend is triggering a SIGSEGV or some other synchronous signal, causing the program to hang until it is killed by cmd/go.

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static void die(const char *s) {
  perror(s);
  exit(EXIT_FAILURE);
}

char *nil;

static void handler(int sig, siginfo_t *info __attribute__((unused)), void *ctxt __attribute__((unused))) {
  printf("SP %#lx\n", (unsigned long)(__builtin_frame_address(0)));
  *nil = 0; /* trigger SIGSEGV */
}

static char *stack[SIGSTKSZ];

int main() {
  stack_t ss;
  struct sigaction sa;

  memset(&ss, 0, sizeof ss);
  ss.ss_sp = &stack[0];
  ss.ss_size = sizeof stack;
  if (sigaltstack(&ss, NULL) != 0)
    die("sigaltstack");

  memset(&sa, 0, sizeof sa);
  sa.sa_sigaction = handler;
  if (sigfillset(&sa.sa_mask) != 0)
    die("sigfillset");
  sa.sa_flags = SA_ONSTACK | SA_RESTART | SA_SIGINFO;
  if (sigaction(SIGWINCH, &sa, NULL) != 0)
    die("sigaction");
  if (sigaction(SIGSEGV, &sa, NULL) != 0)
    die("sigaction");

  raise(SIGWINCH);

  exit(EXIT_SUCCESS);
}

Actually I now suspect the problem is simple enough.  The TestStress test sends signals as fast as possible.  Those signals are sent through sigsend.  sigsend calls notewakeup, which calls semawakeup, which calls pthread_mutex_lock.  In other words, we are calling pthread_mutex_lock from a signal handler.  But we are calling the C function, not making a system call.  The C function pthread_mutex_lock is not async-signal-safe.  If the signal arrives while signal_recv is also locking or unlocking the same mutex, anything could happen.

So after looking through a bunch of docs and complaints, it appears that macOS primitives for communications between threads are limited.
The sem_post function is async-signal-safe, but there is no way to do a timed wait for a semaphore: macOS does not support sem_timedwait, although it is in IEEE Std 1003.1-2001.
I think the best bet is the API defined in <mach/semaphore.h>, which is more or less what we used to use before converting to libc.  That API appears to be available from C, but is sparsely documented.  This would mean calling functions semaphore_create, semaphore_signal, semaphore_wait, semaphore_timedwait, semaphore_destroy, and mach_task_self.  This assumes that semaphore_signal is async-signal-safe; it is not documented as such, but according to the Intertubes sem_post calls it, so it must be.
@randall77 @eliasnaur Do you see any difficulties with using those functions on macOS and iOS?

Thanks for working on this and for taking iOS limitations into account.
https://developer.apple.com/documentation/kernel/1538205-semaphore_create?language=objc only lists macOS, which means that while semaphore_create and friends might exist and work on iOS, Go programs could end up being rejected by the App Store checks. See https://github.com/golang/go/issues/31628 for a recent example with ptrace.
Is the dispatch variant of the semaphore API sufficient? It is listed as supported on all Apple platforms.

What we need is a way to do a timed wait for some condition to occur: wait for up to N nanoseconds for the condition.  Right now we we use a condition variable, and use pthread_cond_timedwait_relative_np for the timed wait, but that doesn't work because we have no way to signal a condition variable in a signal handler.

My next thought is to add a new kind of synchronization construct to the runtime: a signal safe note.  On all platforms other than Darwin, we would implement that as a normal note.  On Darwin we would call sem_open (it's a real pain that Darwin is also missing sem_init) and call sem_post from the signal handler.  This could work because we don't need to do a timed wait on the signal safe note.

Sorry to push the point if it was completely off: did you see my question about the "dispatch" semaphore variants, such as https://developer.apple.com/documentation/dispatch/1452919-dispatch_semaphore_signal?language=objc?

I saw the link but I didn't understand it, and intended to reply to it with my comment about a timed wait.  But looking deeper I see that there is a timed wait there.  Thanks.
What I'm unsure about now is that that page says these are available from Objective C and Swift.  But I do see <dispatch/dispatch.h> which looks like C code.  I will give it a try.

Reopening because rollback was committed.

As an update, the darwin-amd64-10_11 build is now seeing flaky failures again: https://build.golang.org/log/3728af36f8bbb9c6d0341afa90b8afbc1138cf3a

Update on the test failures here at home. As it happens, the "lingering death" that causes the tests to timeout with various issues actually happens after or better said, in the wake of, running signal_test. The run by hand, -v output is:
lum:signal mtj$ go test -v
=== RUN   TestSignal
--- PASS: TestSignal (0.00s)
    signal_test.go:44: sighup...
    signal_test.go:53: sigwinch...
    signal_test.go:60: sighup...
    signal_test.go:63: sighup...
=== RUN   TestStress
--- PASS: TestStress (3.01s)
=== RUN   TestReset
signal: killed

The PASS in TestStress does indeed pass in all cases. Changing the number of CPUs in TestStress to one makes the test pass 3 out of 4 times. Changing various waits and delays does nothing. After TestStress in cases where it triggers the issue, the latent issue puts the next test into the unkillable by ^C mode where it does nothing but vegetate and consume processor time.
I read and understood Ian's deeper causal commentary, but wanted to explore ways to provoke the bug less aggressively as an alternative to preventing the test on darwin. I surrender on that, the test is now skipped in my tree.

FYI, in os_test.go, in PipeThreads, changing the "but can you do it with just half the threads?" test to a more generous 2/3 the threads, works fine on many core...
defer debug.SetMaxThreads(debug.SetMaxThreads((2*threads) / 3))
Line 2278

panic: test timed out after 9m0s

goroutine 50 [running]:
testing.(*M).startAlarm.func1()
        /Users/gert/Desktop/go/src/testing/testing.go:1382 +0xdf
created by time.goFunc
        /Users/gert/Desktop/go/src/time/sleep.go:169 +0x44

goroutine 1 [chan receive]:
testing.(*T).Run(0xc00014a000, 0x41680df, 0x9, 0x4171488, 0x4077901)
        /Users/gert/Desktop/go/src/testing/testing.go:961 +0x377
testing.runTests.func1(0xc0000e2000)
        /Users/gert/Desktop/go/src/testing/testing.go:1207 +0x78
testing.tRunner(0xc0000e2000, 0xc000054dc0)
        /Users/gert/Desktop/go/src/testing/testing.go:909 +0xc9
testing.runTests(0xc0000c2020, 0x426fc60, 0xb, 0xb, 0x0)
        /Users/gert/Desktop/go/src/testing/testing.go:1205 +0x2a7
testing.(*M).Run(0xc0000de000, 0x0)
        /Users/gert/Desktop/go/src/testing/testing.go:1122 +0x176
main.main()
        _testmain.go:66 +0x135

goroutine 18 [syscall]:
os/signal.signal_recv(0x41936c0)
        /Users/gert/Desktop/go/src/runtime/sigqueue.go:139 +0x9f
os/signal.loop()
        /Users/gert/Desktop/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
        /Users/gert/Desktop/go/src/os/signal/signal_unix.go:29 +0x41

goroutine 35 [runnable]:
runtime.Gosched(...)
        /Users/gert/Desktop/go/src/runtime/proc.go:269
os/signal.signalWaitUntilIdle()
        /Users/gert/Desktop/go/src/runtime/sigqueue.go:172 +0x30
os/signal.Stop(0xc000070360)
        /Users/gert/Desktop/go/src/os/signal/signal.go:196 +0x18c
runtime.Goexit()
        /Users/gert/Desktop/go/src/runtime/panic.go:547 +0xec
testing.(*common).FailNow(0xc00014a000)
        /Users/gert/Desktop/go/src/testing/testing.go:653 +0x39
testing.(*common).Fatalf(0xc00014a000, 0x416b1c4, 0x16, 0xc000144ce0, 0x1, 0x1)
        /Users/gert/Desktop/go/src/testing/testing.go:716 +0x90
os/signal.waitSig(0xc00014a000, 0xc000070300, 0x41936c0, 0x418f928)
        /Users/gert/Desktop/go/src/os/signal/signal_test.go:32 +0x247
os/signal.testCancel(0xc00014a000, 0x4b7e59ccf9200)
        /Users/gert/Desktop/go/src/os/signal/signal_test.go:133 +0x20f
os/signal.TestReset(0xc00014a000)
        /Users/gert/Desktop/go/src/os/signal/signal_test.go:187 +0x30
testing.tRunner(0xc00014a000, 0x4171488)
        /Users/gert/Desktop/go/src/testing/testing.go:909 +0xc9
created by testing.(*T).Run
        /Users/gert/Desktop/go/src/testing/testing.go:960 +0x350

goroutine 8 [runnable]:
runtime.Gosched(...)
        /Users/gert/Desktop/go/src/runtime/proc.go:269
os/signal.signalWaitUntilIdle()
        /Users/gert/Desktop/go/src/runtime/sigqueue.go:172 +0x30
os/signal.Stop(0xc00009c120)
        /Users/gert/Desktop/go/src/os/signal/signal.go:196 +0x18c
os/signal.TestStress.func1(0xc000088120, 0xc000088180)
        /Users/gert/Desktop/go/src/os/signal/signal_test.go:92 +0x17d
created by os/signal.TestStress
        /Users/gert/Desktop/go/src/os/signal/signal_test.go:79 +0xf8
FAIL    os/signal       540.019s

@gertcuykens Thanks.  I think we understand exactly what is happening, and we don't need further examples.  What we need is some idea of how to fix it.  iOS doesn't seem to have the facility we need.

I'm not enrolled in the Apple Developer program to be sure, but a good test of whether symbols are available for iOS is to check whether they're available in the Objective C headers. I created a single page iOS project in Xcode and modified main.m:
#import <UIKit/UIKit.h>
#import <mach/semaphore.h>
#import <mach/task.h>
#import <mach/mach.h>

/*#include <sys/types.h>
#include <sys/ptrace.h>
*/

#import "AppDelegate.h"

int main(int argc, char * argv[]) {
    semaphore_t sem;
    task_t me = mach_task_self();
    semaphore_create(me, &sem, 0, 0);
    semaphore_signal(sem);
    semaphore_wait(sem);
    mach_timespec_t ts;
    semaphore_timedwait(sem, ts);
    semaphore_destroy(me, sem);

     //    ptrace(0, 0, 0, 0);
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

Which compiled without errors.
As you can tell, I also tried to use a symbol we know is not available: ptrace. As expected, the ptrace symbol is not defined in ptrace.h for iOS and the build fails.
I think we can go ahead and use your suggested C functions, Ian. In the meantime, perhaps someone with Apple Developer access can make absolutely sure the functions pass the App Store tests. @steeve, @sanderpick?

I went with a different approach that should always work: use a special purpose note, based on a pipe, for signal handling.  @eliasnaur It would be great if you could check that CL 184169 works on arm and arm64.  Thanks.  I verified that it seems to work on amd64, using gomote.


Add AniTora source (PT-BR)

Source name
AniTora
Source link
https://anitora.ru/
Source language
Português (Brasil)
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a title with source name.
[X] I have checked that the extension does not already exist by searching the GitHub repository and verified it does not appear in the code base.
[X] I will fill out all of the requested information in this form.

I have the base code to work with this source, but the m3u8 files has a image header that broke it.
We need to find something like skip_initial_bytes=25 of FFMPEG to work with this.

I have the base code to work with this source, but the m3u8 files has a image header that broke it.
We need to find something like skip_initial_bytes=25 of FFMPEG to work with this.

Ok, no problem. Too bad I don't understand anything about it.

This source is down


how to add starling framework to my project

I am unable to add starling framework to my project, I have starling folder inside the project folder but getting error Type was not found!
Please help!

dont know what went wrong, everything is now working after a restart!


Adding custom fields to user in FaunaDB adapter

Question around best practices...
For the fauna DB adapter, let's say we had a bunch of other profile information on the user, would you recommend forking the adapter and adjusting the create and update user functions to suit project requirements? Or would you recommend another collection in fauna like 'profiles' that has a ref to the user collection?

Hi dsbrianwebster, thanks for the question!
Currently I'd recommend another collection that refs the next-auth user collection.
However, someone recently added a PR to support custom fields in the User colleciton in the typeorm adapter. We're currently working on getting it merged and would like to extend that functionality to all adapters then :+1:

Yes, I also think this would be very cool. I had a similar usecase so many times. One workaround that I have been using in my projects is to add everything I receive from profile callback to the user object — instead of only taking the relevant fields and adding them.

Although, I think this would make it harder to type the functions, if we do like I said(adding everything we receive in profile callback to user)

As there is current no way to do this, I am going to close this issue for the time being.
There is discussion in #43 about adding the ability to import custom models, however. So that seems like the most appropriate place to continue that discussion.
Feel free to reopen if need be.


Add sample code

Here's the sample code I wrote for the kids in the hopes that it will help others too. I'm writing Swift soon and hope to offer you all good advice.

Can you update your branch with our master?


Update dsb28.json

Added Clamp 3 meters and corrected 1 mistake

Not all devices have three clamps and defining these for ones that don't can cause issues. Can you confirm your deviceType and deviceId? Firmware version? We're going to have to see if we can condition these somehow.

As you can see n the attached photo, my device has name DSB28-ZWEU and it has 3 clamps for 3 phases.
Also you can read its user manual: https://aeotec.freshdesk.com/support/solutions/articles/6000166671-home-energy-meter-g2-user-manual- (please read "Diagram of EU/AU Version(3 Phases,4 Wires)" article), and you can download  Excel table (HEM Calculator) with its parameters: https://aeotec.freshdesk.com/helpdesk/attachments/6103459970

That's not the info I need. From zjs2mqtt or HA, what's the deviceType, deviceID and firmware version? I need the device's fingerprint.

That's not the info I need. From zjs2mqtt or HA, what's the deviceType, deviceID and firmware version? I need the device's fingerprint.

I don't fully understand where I can get the information you need. Maybe this screenshot will answer your question?

@blhoward2 there were already other settings for clamp 3 in that file. Looks like an oversight to me.


feat(pacer.email): multi docket NEF bankruptcy short description

Changes are basically putting the old parsing inside a for loop, accumulating parsed short_descriptions and choosing the best looking. It doesn't break past examples and will allow us to add the short_description field for multi docket NEFs (we say "multi" but have only seen 2 docket NEFs). Check the GH issue for graphic examples
Solves: #914
Solves:
COURTLISTENER-6Q7
COURTLISTENER-6Q8
COURTLISTENER-6QV
COURTLISTENER-71E

Also, do you know if the short descriptions are always the same for all the items in a multi-doc NEF?

I don't know with certainty. I would guess from the few examples I have seen, and the general structure of NEF emails:
The only type of "multi" docket NEF we have examples of are 2-docket NEF. Most of them have a subject related to Adversary Case ..something.... It seems to me the logic is that some "single documents" (which may actually be more than a document, considering attachments) become a docket entry mirrored on both linked dockets. In that sense, the subject and short description should be the same, since there is a "single document"

there is a "single document"

That's my assumption too. If we lean into that, does that change your code?

Implemented in https://github.com/freelawproject/juriscraper/pull/1276


Trace missing on map

I was looking at coverage today and saw some blank places on the map where I thought I had already uploaded images. I was about to re-upload when I noticed that in JOSM, the plugin was showing images along these roads. But they are not showing as having coverage on the map.
Possibly a re-opening of #1 although that may have just been the weird tile display problem (#36). This is definitely not #36 though. The trace doesn't show up no matter where you pan/zoom.
Some specific examples:

http://openstreetcam.org/details/8916/590 should indicate coverage through Wathena
http://openstreetcam.com/details/24799/2500 should indicate coverage from Kansas City to Columbia, MO along I-70
Both http://openstreetcam.com/details/8454/1031 and http://openstreetview.com/details/8471/527 should indicate coverage along US 36 from the Colorado border and St. Francis.

I am seeing the same issue. Some of my traces are not shown on the map, and the traces that are shown on the map cannot be selected correctly, i.e. I cannot set a dot, and regardless of where I click on the trace, it shows the last image of the trace.
Does not show up on map:
http://openstreetcam.org/details/29075/1
Only shows last image of trace:
http://openstreetcam.org/details/29082

All of my examples now show up correctly on the map.

Since @ToeBee has confirmed that the tracks have shown up correctly, we will close this ticket.


[KED-1371] Confusion around notebooks in Spaceflight Tutorial

There is some confusion at the point where the spaceflight tutorial starts talking about Jupyter notebooks since they are not introduced.
https://kedro.readthedocs.io/en/latest/03_tutorial/04_create_pipelines.html
Section: "Creating a master table"
We need to add a function to join together the three dataframes into a single master table in a cell in the notebook as follows:

Hi 👋, thanks for raising this! The start of the guide does mention Jupyter notebooks briefly, but I agree that the rest of the guide doesn't really talk about notebooks much and then suddenly brings it up again in that section. I'll tag this with our internal ticket number to help keep track of it.

Hello @Arcticnode, hope you are all good :)
Ever since you raised this issue we revamped the Table of Contents on our docs. We also released a updated version of the SpaceFlights tutorial.
Have you had a chance to check it out? Let us know what you think!
Also, are you happy for me to close this ticket?

Hello @Arcticnode, hope you are all good :)
Ever since you raised this issue we revamped the Table of Contents on our docs. We also released a updated version of the SpaceFlights tutorial.
Have you had a chance to check it out? Let us know what you think!
Also, are you happy for me to close this ticket?

Yes, I am happy with that. Thank you for taking my comment into consideration! :)


No Module named 'google'

I tried the simplest solution first, I tried to download 'google'
which success fully installed 3 new modules: Google. BeautifuSoup4 and Soupsieve
However, upon reruuing auto_run.py
The same error is returned, and Ii even tried to reinstall thinking that something might have went wrong, bb ut nothin changes

HI I just clone the project and installed all the requirements with the requirements provided still no error occurs.
Kindly try "pip install -r requirements.txt"


fix display glitch of download progress

$ elan update stable
info: syncing channel updates for 'stable'
info: latest update on stable, lean version v4.0.0-m5
info: downloading component 'lean'
  6.9 MiB / 139.1 MiB (  5 %)   0 B/s ETA: Unknown                 19.1 MiB / 139.1 MiB ( 14 %)   6.9 MiB/s ETA:  17 s
               30.2 MiB / 139.1 MiB ( 22 %)   9.5 MiB/s ETA:  11 s                 41.4 MiB / 139.1 MiB ( 30 %)  10.1 MiB/s ETA:  10 s                 52.5 MiB / 139.1 MiB ( 38 %)  10.3 MiB/s ETA:   8 s                 63.6 MiB / 139.1 MiB ( 46 %)  10.5 MiB/s ETA:   7 s                 74.7 MiB / 139.1 MiB ( 54 %)  11.3 MiB/s ETA:   6 s                 86.0 MiB / 139.1 MiB ( 62 %)  11.1 MiB/s ETA:   5 s                 97.1 MiB / 139.1 MiB ( 70 %)  11.2 MiB/s ETA:   4 s
          108.3 MiB / 139.1 MiB ( 78 %)  11.2 MiB/s ETA:   3 s                119.4 MiB / 139.1 MiB ( 86 %)  11.2 MiB/s ETA:   2 s                130.6 MiB / 139.1 MiB ( 94 %)  11.2 MiB/s ETA:   1 s                139.1 MiB / 139.1 MiB (100 %)  11.2 MiB/s ETA:   0 s
info: installing component 'lean'

  stable installed - Lean (version 4.0.0, commit 7dbfaf9b7519, Release)

The download progress is bad displayed.
Add carriage return (\x0d) to fix it.
$ elan update stable
info: syncing channel updates for 'stable'
info: latest update on stable, lean version v4.0.0-m5
info: downloading component 'lean'
139.1 MiB / 139.1 MiB (100 %)  11.0 MiB/s ETA:   0 s
info: installing component 'lean'

  stable installed - Lean (version 4.0.0, commit 7dbfaf9b7519, Release)

Pull requests without meaningful description are not acceptable

Description has been updated.

There is already a call to term.carriage_return(), is it clear why that doesn't work? When in doubt, please instead port over fixes from rustup upstream, who seem to have relevant changes.

Rustup implements a new terminal interface by themself. They also use ANSI escape code \r or \x0d to achieve carriage return.
terminalsource.rs#L172-L180
Copying this file and dealing with all dependencies and references is a hard work. So I only copy some snippets, and use \r directly.
For filling spaces before carriage return, it is because last line may be longer than next line. So filling a fixed quantity of spaces is  not enough in this case. Use displayed_charcount to count the spaces of last line instead.

Okay, looks reasonable to me. Thanks for investigating.
I assume you sucessfully tested it on Windows?

Okay, looks reasonable to me. Thanks for investigating.
I assume you sucessfully tested it on Windows?

Yes, it's latest Windows 10.


November 4th English Translations

From:
rake locale:update_all
There are roughly 10-15 new and removed strings.

Marking for backport since it looks like some new/updated english strings will be lacking various language translations.


panic: interface conversion: interface {} is nil, not []interface {}

I got this issue, "panic: interface conversion: interface {} is nil, not []interface {}",  while running:
terraformer plan aws --filter=vpc={my-vpcid} --regions=us-east-2 --resources="*"
Here is the stack trace:
goroutine 1 [running]:
github.com/GoogleCloudPlatform/terraformer/providers/aws.(*Ec2Generator).PostConvertHook(0x14000c0a360, 0x10191c1ec, 0x14000c0a360)
github.com/GoogleCloudPlatform/terraformer/providers/aws/ec2.go:99 +0x36c
github.com/GoogleCloudPlatform/terraformer/providers/aws.(*AwsFacade).PostConvertHook(0x14000995260, 0x10a1ea3d0, 0x14000995260)
github.com/GoogleCloudPlatform/terraformer/providers/aws/aws_facade.go:75 +0x34
github.com/GoogleCloudPlatform/terraformer/terraformutils.(*ProvidersMapping).CleanupProviders(0x140021ff518)
github.com/GoogleCloudPlatform/terraformer/terraformutils/providers_mapping.go:175 +0xc4
github.com/GoogleCloudPlatform/terraformer/cmd.Import(0x10a1da638, 0x1400092e7d0, 0x140012d4000, 0x50, 0x80, 0x10f01a878, 0x0, 0x0, 0x10790a0a1, 0x1e, ...)
github.com/GoogleCloudPlatform/terraformer/cmd/import.go:104 +0x23c
github.com/GoogleCloudPlatform/terraformer/cmd.importRegionResources(0x1400129e140, 0x1, 0x1, 0x10f01a878, 0x0, 0x0, 0x10790a0a1, 0x1e, 0x10787ee24, 0x9, ...)
github.com/GoogleCloudPlatform/terraformer/cmd/provider_cmd_aws.go:112 +0x180
github.com/GoogleCloudPlatform/terraformer/cmd.newCmdAwsImporter.func1(0x140010f5b80, 0x140011c1500, 0x0, 0x3, 0x0, 0x0)
github.com/GoogleCloudPlatform/terraformer/cmd/provider_cmd_aws.go:51 +0x250
github.com/spf13/cobra.(*Command).execute(0x140010f5b80, 0x140011c14d0, 0x3, 0x3, 0x140010f5b80, 0x140011c14d0)
github.com/spf13/cobra@v1.1.1/command.go:850 +0x320
github.com/spf13/cobra.(*Command).ExecuteC(0x14000ec8b00, 0x14000f9c600, 0x14000112050, 0x109ebaa88)
github.com/spf13/cobra@v1.1.1/command.go:958 +0x258
github.com/spf13/cobra.(*Command).Execute(...)
github.com/spf13/cobra@v1.1.1/command.go:895
github.com/GoogleCloudPlatform/terraformer/cmd.Execute(0x109fd7f08, 0x14000f9c6c0)
github.com/GoogleCloudPlatform/terraformer/cmd/root.go:36 +0x24
main.main()
github.com/GoogleCloudPlatform/terraformer/main.go:39 +0x50
I was able to resolve this issue by terminating the one EC2 that was in a stopped state. This whas something todo with the RootDeviceVolume associated with the stopped EC2. It would seem terrafomer should handle this condition, but you can work around it either by terminating or excluding that EC2.
It is unclear to me if this would happen for any EC2 in a stopped state or if there was something specific in my EC2 that caused this problem. I thought it would be useful to share for others.

I looked into this a little more. This was a very old instance. I had stopped the EC2 and deleted the EBS, but left the EC2 in a stopped state. This is likely the problem as terraformer was trying to find the EBS volume and it wasn't there. Looks to be a corner-case.


Update Maven plugin docs for JAXB 3

Closes https://github.com/eclipse-ee4j/jaxb-ri/pull/1506

We spent some time to add JAXB 3 support to the two most popular Maven plugins. The existing plugins that were in the documentation only support JAXB 2.2. At the moment these two plugins to the best of our knowledge (Maven Central) are the only plugins that support JAXB 3.

@lukasj As requested.

@adamretter eca check failed, likely due to missing sign-off in the commit . Can you try to git commit -s --amend followed by git push -f?


Moving to v2 preview task. Nunit3 support

You should take the major-version bump opportunity to switch over to the new find functions for consistency for in the box tasks.

Yes, the work is in progress :)


Incompatible types in typeclass instances are not caught by the checker

While looking into why the standard library wasn't building correctly for me, I found that that readByte for StandardInput
was trying to call an incompatible mono in the generated c code.
In the source I found that the implementations of the readByte and writeByte functions in the instances for StandardInput and StandardError respectively did not have the correct types in the function definition.
The typeclass definition demands that the instance type parameter matches the stream type
-- standard/src/IO/IO.aui
typeclass ByteInputStream(T: Type) is
    generic [R: Region]
    method readByte(stream: &![T, R]): Option[Nat8];
end;

But the implementation does not follow this
-- standard/src/IO/Terminal.aum
instance ByteInputStream(StandardInput) is
    generic [R: Region]
    method readByte(stream: &![StandardOutput, R]): Option[Nat8] is
        let stdin: Address[Nat8] := getStdin();
        let res: Int32 := fgetc(stdin);
        if res = EOF then
            return None();
        else
            return toNat8(res);
        end if;
    end;
end;

I have created a PR to fix the discrepancy in this code, but surely this should be getting caught by the type checker?

Yes this is absolutely a bug in the type checker. Thanks for reporting and fixing the code!


[tf.data] graduate OptimizationOptions from experimental to tf.data

This PR graduates tf.data.experimental.OptimizationOptions to tf.data.OptimizationOptions.

[x] deprecate the old endpoint
[x] update docstring of the class
[x] Modify the __getattr__ and __setattr__ implementation of dataset_ops.Options for backward-compatibility
[x] regenerate golden APIs.
[x] add/modify relevant test cases for the new endpoint.
[x] update RELEASE.md

TEST LOG
INFO: Elapsed time: 32.496s, Critical Path: 28.35s
INFO: 354 processes: 133 internal, 221 local.
INFO: Build completed successfully, 354 total actions
//tensorflow/python/data/kernel_tests:options_test                       PASSED in 4.3s

INFO: Build completed successfully, 354 total actions

cc: @jsimsa

@kvignesh1420 thank you for the PR. FYI, I am working on removing some unused experimental optimization options that I would prefer to merge before your CL (so that we avoid moving some options only to remove them soon after).
On a related note, the branch cut for TF 2.6 is scheduled for 6/24. I am hoping to get my changes in in the next couple of days (and then your PR in before the branch cut).
Also, please take a look at the changes I made to your ThreadingOptions PR (https://github.com/tensorflow/tensorflow/commit/120ae92ab198392c7092176fd60a5049e0b7ac5a). The original approach (of maintaining both threading and experimental_threading) broke internal tests and so I switched to only keeping threading and having experimental_threading being re-routed to threading.

@jsimsa I have made the initial python level changes for the new AutotuneOptions class and autotune_options Options attribute. Will make the changes to the .cc files after your CL.

could we separate the AutotuneOptions change into a separate PR (which we could merge ahead of this PR) that would also include the C++ changes? thanks

@jsimsa sure will create a new PR for AutotuneOptions change.

@jsimsa  created the PR https://github.com/tensorflow/tensorflow/pull/50291 for addressing AutotuneOptions

@kvignesh1420 Can you please resolve conflicts? Thanks!

@kvignesh1420  Any update on this PR? Please. Thanks!

@jsimsa as you have covered the autotune options promotion in https://github.com/tensorflow/tensorflow/commit/c64634eb47f6581a7cf0cb01cf30284ff480d330, shall I continue with this PR? Please let me know.
cc: @aaudiber

I would prefer to handle options related changes myself. My suggestion is to close this PR and prioritize other work suggested by @aaudiber (e.g. migrating sample_from_datasets to core API so that rejection_resampling implementation can stop depending on experimental API).

@jsimsa okay, sure!


[berkeley] Add 'merges cleanly to rampup' CI job

This is https://github.com/MinaProtocol/mina/pull/14947 merged through to rampup.

!ci-build-me

!approved-for-mainnet


Loader for one component blocks resolution for all other components

First of thank you for putting this together. Since Remix is still relatively new, examples are always appreciated. Your component data approach here is interesting, but there's a sort of critical issue that I'm hoping there is a good way to solve.
I've put together a brief example of the issue here on my fork here. Basically, I just added a 5 second blocking timeout to one of the Component loaders. Since the index loader requires all of the Component loaders to run, it can't complete the resolution for any of the components until the one with the 5 second delay finishes.
My initial thought is that the components need to be treated as child views so they can resolve their own data, but that seems like that could get messy really quick. Any ideas about the best way to approach this?

Sorry, I missed this. Yeah, that's just the nature of how loaders work. Remix will call ALL loaders in parallel. It's treating all the nested loaders for the route as a single logical "request", since you're saying I need all this data to render my page.
If you have a loader that takes a long time, then I would try to cache that (if possible), or simply skip it and fetch it from the client.
Loaders don't magically solve your app needs. You need to weight the tradeoffs and solve the problem with the tools provided (not you specifically).

I'm new to Remix, and this repo has been really helpful in piecing together my logical understanding for supporting paradigms in-which component logic needs to be encapsulated because components on the page might not be known until runtime (CMS integration, for example).  My first question after looking through the code was whether data retrieval of components was truly consecutive & blocking... so thanks to both of you for putting this in the public domain.
At the risk of sounding like a complete amateur, I'm curious if this problem could be solved by Remix Streaming, now that Remix supports that feature of React 18 in v1.11?

Yes. I plan to update the POC to support the new defer streaming feature.


Review

Please review, @klausfoerster

Description of repository
The code is used to calculate the reactive, active and apparent power. Afterwards, based on the result of the reactive power, it will be determined whether it is a capacitive or inductive reactive power. Subsequently, values are assigned to the variables and the calculation is executed. The results are then output
Tests
-[x] License exists

[ ] Create a fork and start a pull-request

[ ] Pytests fails as expected
[ ] Ruff linter fails as expected

Description of repository
The code replicates the basic functions of a calculator.
Two numbers can be solved using addition, subtraction, division and multiplication.
Divisions by zero are excluded.
Tests

[x] License exists
[x] Create a fork and start a pull-request
[ ] Pytests fails as expected
[ ] Ruff linter fails as expected

Submission of second homework assignment, @danielhuppmann


[Feature Request] Collaborative/Access Control enhancement

As discussed in issues #1735 and #1725, enhancing the collaborative capabilities of LangFlow can significantly improve user experience, particularly in team-based environments. This feature request outlines proposed improvements in authentication/role management, cross-account flow sharing, asynchronous updates, and flow version management.
Proposed Enhancements:

Improved Authentication and Role Management:

Objective: Implement a more robust authentication system to support varying levels of user permissions.
Implementation:

Integrate OAuth2 with current authentication systems to enable more secure and flexible user management.
Develop roles such as Admin, Editor, and Viewer, each with different permissions regarding the creation, editing, and viewing of flows.

Cross-Account Flow Sharing:

Objective: Enable users to share workflows across different accounts, enhancing collaborative efforts.
Implementation:

Create a sharing interface where users can invite others to access workflows by email or user ID.
Implement sharing permissions that allow users to set read-only or edit rights for each shared user.

Asynchronous Updates and Notifications:

Objective: Allow users to receive updates on shared flows asynchronously, ensuring all collaborators are kept up-to-date.
Implementation:

Utilize WebSockets for real-time data transfer to enable live updates without requiring page refreshes.
Integrate a notification system that alerts users to changes or comments in shared flows.

Flow Version Management:

Objective: Implement a version control system for flows to track changes over time and enable rollback to previous versions if needed.
Implementation:

Develop a version history feature that records each change made to a flow, along with the user who made the change and the time.
Provide an interface to view version history and revert to previous versions when necessary.
Technical Considerations:

Ensure that all new features adhere to best practices in security and data privacy.
Consider the scalability of the solution to accommodate a growing number of users and workflows.
Impact:
These enhancements will streamline collaborative efforts, improve security, and make LangFlow a more robust tool for both individual users and teams. They will also address current limitations noted by users, fostering a more efficient and user-friendly environment.

Hey @jaschahuisman
These are awesome and some of them are in our (internal) roadmap.
We plan on using Casbin for the RBAC/ABAC.
Do you have the expertise for any of these? We can collaborate on them if you like.

No experience in Casbin here. Where can I find the roadmap? (curious 👀)

+1 on this.
"Utilize WebSockets for real-time data transfer to enable live updates without requiring page refreshes."
Would love this!

How is the progress?
I want to contribute to  this feature.

I was reading about how other frameworks deal with federated authentication. Here is an example of how Open Web UI integrates it: https://docs.openwebui.com/tutorial/sso/. I know the Langflow will leverage Casbin library to enable SSO. but if it is too complex can we implement something similar to what Open Web UI did?
I started replicating, I added in the create_app function in langflow/src/backend/base/langflow/main.py, two paths:
################################
### Integrate Google OAuth 2.0
################################

import os
import json
from starlette.config import Config
from authlib.integrations.starlette_client import OAuth
from starlette.middleware.sessions import SessionMiddleware
from starlette.responses import RedirectResponse

#######################
## Load OAuth variables
#######################
oauth_config_json = json.loads(os.environ["OAUTH_CFG"])
GOOGLE_CLIENT_ID=oauth_config_json['web']['client_id']
GOOGLE_CLIENT_SECRET=oauth_config_json['web']['client_secret']
SECRET_KEY = os.environ.get("SECRET_KEY") or "a_very_secret_key"

###################
## OAuth setup
###################
config_data = {'GOOGLE_CLIENT_ID': GOOGLE_CLIENT_ID, 'GOOGLE_CLIENT_SECRET': GOOGLE_CLIENT_SECRET}
starlette_config = Config(environ=config_data)
oauth = OAuth(starlette_config)
oauth.register(
    name='google',
    server_metadata_url='https://accounts.google.com/.well-known/openid-configuration',
    client_kwargs={'scope': 'openid email https://www.googleapis.com/auth/bigquery'},
)

app.add_middleware(
    SessionMiddleware,
    secret_key=get_settings_service().auth_settings.SECRET_KEY.get_secret_value()
    )

@app.get("/logingoogle")
async def google_login(request: Request):
    redirect_uri = request.url_for("login_to_get_access_token")
    print("Redirecting to", redirect_uri)
    return await oauth.google.authorize_redirect(request, redirect_uri)

@app.get("/logincallback")
async def login_to_get_access_token(
    request: Request,
):
    try:
        # 1. get token from google server
        access_token = await oauth.google.authorize_access_token(request)
       # ****rest of code here****
    except Exception as exc:
        if isinstance(exc, HTTPException):
            raise exc
        raise HTTPException(
            status_code=500,
            detail=str(exc),
        ) from exc

    return RedirectResponse(url='/')

My challenge is how to modify the typescript logic to redirtect to /googlelogin rather than the default /login. FYI, Typescript is not my strength.
Any help is much appreciated!!

Hi @ogabrielluiz, is Casbin still in the roadmap?

This is an important feature

Very important in Enterprise, I work at edenred.com and I'm in charge of GenAI transformation and tooling, I want to implement this tool internally for our teams but lack of SSO will get me challenged by the security team :(

This list is very important, i love all points!


populate newly required env vars in receiver/dispatcher

The recent merge of https://github.com/knative-sandbox/eventing-kafka/pull/133 has broken the distributed kafka channel implementation.  It added new required environment variables to the receiver/dispatcher but failed to populate them in Deployment created by the controller.  This PR provides the missing logic to do so.

Note - This was not caught by automated testing because we are still in the process of standing up our e2e (integration) tests.  All unit tests were/are passing.

/LGTM


Message typo correction

This commit fixes a typo in the "Trade should be finalized shortly" message, as well as updates other messages sent to users. This change is very small, and most likely does not warrant its own version change

always create a pull request to merge into development branch.

Please also do the grammatical correction in Commands.ts > accepttradeCommand function.

Please also do the grammatical correction in Commands.ts > accepttradeCommand function.

All set! Let me know if you catch anything else that needs to be updated.

Thank you! All looks good for now. I will merge this to the development branch and will look for more


.scheduler() Initialization function is not working on click event of an Anchor or button.

I am calling initialization function on click event of an anchor.
$(document).ready(function(){
$('.call-scheduler').on('click', function(){
$('.scheduler').scheduler();
});
});
Error i get once the click event is raised: TypeError: $(...).scheduler is not a function
However to diagnose this issue i call the initialization function inside document ready itself and it worked fine. I think intialization is not working on click event of the anchor or button.Can anybody help me on this. I have included the dependencies mentioned below.

<script type="text/javascript" src="//code.jquery.com/jquery-1.11.0.js"></script>
<script type="text/javascript" src="//maxcdn.bootstrapcdn.com/bootstrap/3.1.1/js/bootstrap.js"></script>
<script type="text/javascript" src="//cdn.jsdelivr.net/handlebarsjs/1.3.0/handlebars.js"></script>
<script type="text/javascript" src="//www.fuelcdn.com/fuelux/3.5.0/js/fuelux.js"></script>

Here's a working example that illustrates initialization on click of a button.  Does this work for you?  If not, could you provide a complete example of your code.


Loongarch CI build

With the introduction of Loongarch64 assembly in #21704, we ought to have a CI loop that at least builds and preferably emulates the test suite.
We should cover Loongarch64 and Loongarch32 if possible, although only Loongarch64 has code currently in tree.
Qemu supports the platform, however our CI runners are using a version that is too old to do so, so some work will be required.

I ever built a  CI system for project DPDK on LoongArch host based on the toolset of dpdk-ci. In dpdk-ci there is a script to poll the new patch submitted to DPDK's patchwork and download the patch to compile and execute the unit tests on LoongArch host. After the CI test done sending the test results to the patchwork by email, like this. Can we build the CI loop as this method? I can put as much work as possible for adding the CI loop.

Will it be acceptable if we can provide .deb packages for LoongArch toolchain and QEMU for GitHub CI?