time: make Timer/Ticker channels not receivable with old values after Stop or Reset returns

In https://github.com/golang/go/issues/14383#issuecomment-220657111, @rsc said:

There is an argument for making
tr := time.NewTimer(0)
tr.Stop()
// There may or may not be a value in the channel now. But definitely
// one should not be added after we receive it.
select {
        case <-tr.C:
        default:
}

work, but it doesn't today, and we're certainly not going to do that for Go 1.7. Maybe early in Go 1.8 if someone wants to file a different bug.

As far as I can tell, no different bug was filed: the documentation for (*Timer).Stop still says:
https://github.com/golang/go/blob/7d2473dc81c659fba3f3b83bc6e93ca5fe37a898/src/time/sleep.go#L57-L66
and that behavior is still resulting in subtle bugs (#27169). (Note that @rsc himself assumed that a select should work in this way in https://github.com/golang/go/issues/14038#issuecomment-219909704.)
I think we should tighten up the invariants of (*Timer).Stop to eliminate this subtlety.
CC @empijei @matttproud @the80srobot @ianlancetaylor

For an example program illustrating why a user might reasonably expect (and attempt to make use of) this behavior, see https://play.golang.org/p/NmCz6km7nAA.

Thanks for filing this.
I also found this behavior puzzling and apparently I got it wrong too as I was expecting no values to be sent after t.Stop() returned.
If, as I understand now, a value might be sent after the call to Stop has returned, is there any way to correctly re-use a timer?

If, as I understand now, a value might be sent after the call to Stop has returned, is there any way to correctly re-use a timer?

If you know that no other goroutine is receiving on the C channel, then you can receive unconditionally after the call to Stop, and it won't actually matter whether the value was delivered before or after the call to Stop returned.
(The select-with-default after Stop is where the bug occurs, and none of the examples in your post do that — and they don't need to, because in your examples the reads on t.C are all on the same goroutine as the calls to t.Stop.)

In the current implementation, this can probably be done by changing runOneTimer to move the Cas away from timerRunning until after the invocation of f.

Added to proposal process to resolve whether to do this, after mention in #38945.

This made its first appearance in the proposal minutes last week.
You can imagine ways to break Go programs with this, such as by
t := time.NewTimer(1*time.Second)
time.Sleep(2*time.Second)
t.Stop()
<-t.C

This would succeed today, but if we clear the channel during Stop it would start blocking.
We would have to define that in the case where Stop pulls the element back out of the channel buffer, it returns true, meaning it "stopped" the timer (false means the timer already expired; expired would now mean "expired and was observed by a channel receive on t.C").
On the other hand, there is technically a race here, and it's not guaranteed that this snippet never blocks, especially on a loaded system. The correct snippet, even today, is:
t := time.NewTimer(1*time.Second)
time.Sleep(2*time.Second)
if !t.Stop() {
    <-t.C
}

That example would be unaffected, because Stop would pull the buffered element back out of the channel and then return true, signaling to the caller that there is nothing to receive.
We could make the change at the start of a release cycle and be ready to roll it back if real (as opposed to hypothetical) problems arose.
Thoughts?

While I like the behavior of pulling the value back out of the channel and having Stop return true, I don't think it is actually backward-compatible, depending on how the len builtin for channels interacts with the memory model.
For example, this program today is not reported as a race and is guaranteed to never block, but would deadlock if Stop clears the channel:
package main

import (
        "fmt"
        "time"
)

func main() {
        t := time.NewTimer(1 * time.Second)
        for len(t.C) == 0 {
                time.Sleep(time.Millisecond)
        }
        t.Stop()
        <-t.C
        fmt.Println("ok")
}

That is why I had restricted my original proposal to guarantee only that no value is sent after Stop returns.

Sorry, I'm not sure I understand what it means to guarantee that no value is sent on the channel after Stop returns.  As far as I can see, that is already guaranteed--maybe not in the documentation, but certainly in the implementation.  What is the actual change that you are suggesting?

@ianlancetaylor, the program given in https://play.golang.org/p/Wm1x8DmYoQo should run indefinitely without reporting any delayed times. Instead, it reports a nonzero rate of delayed timer sends.
On my Xeon workstation:
example.com$ gotip version
go version devel +b2ce3931 Tue May 26 22:28:45 2020 +0000 linux/amd64

example.com$ gotip run main.go
Timer stopped at 2020-05-27 22:16:46.951252699 -0400 EDT m=+2.886904949 subsequently received time
                 2020-05-27 22:16:46.951252454 -0400 EDT m=+2.886904697.
Timer stopped at 2020-05-27 22:17:00.794561424 -0400 EDT m=+16.730213661 subsequently received time
                 2020-05-27 22:17:00.794559263 -0400 EDT m=+16.730211512.
Timer stopped at 2020-05-27 22:17:00.774413697 -0400 EDT m=+16.710065937 subsequently received time
                 2020-05-27 22:17:00.77440917 -0400 EDT m=+16.710061421.
Timer stopped at 2020-05-27 22:17:03.679525664 -0400 EDT m=+19.615177943 subsequently received time
                 2020-05-27 22:17:03.679522832 -0400 EDT m=+19.615178663.
Timer stopped at 2020-05-27 22:17:06.024962313 -0400 EDT m=+21.960614549 subsequently received time
                 2020-05-27 22:17:06.024960025 -0400 EDT m=+21.960612270.
Timer stopped at 2020-05-27 22:17:06.692670731 -0400 EDT m=+22.628322974 subsequently received time
                 2020-05-27 22:17:06.692669848 -0400 EDT m=+22.628322092.
Timer stopped at 2020-05-27 22:17:22.942118175 -0400 EDT m=+38.877770415 subsequently received time
                 2020-05-27 22:17:22.942117468 -0400 EDT m=+38.877769713.
Timer stopped at 2020-05-27 22:17:22.901857123 -0400 EDT m=+38.837509358 subsequently received time
                 2020-05-27 22:17:22.901855958 -0400 EDT m=+38.837508205.
Timer stopped at 2020-05-27 22:17:27.342696328 -0400 EDT m=+43.278348567 subsequently received time
                 2020-05-27 22:17:27.342693224 -0400 EDT m=+43.278345463.
Timer stopped at 2020-05-27 22:17:28.993568136 -0400 EDT m=+44.929220391 subsequently received time
                 2020-05-27 22:17:28.993571601 -0400 EDT m=+44.929223839.
Received 10 delayed times after 128517449 iterations.

Thanks for the example.  If the code is written per the documentation of time.Timer.Stop, it works correctly (https://play.golang.org/p/KlC__ujuE5M).
And now I see how this happens.  It's because in runOneTimer we set the status to timerNoStatus before we call the function that sends a value on the channel, which permits deltimer and therefore time.Timer.Stop to return false before we send the value.  The return of false does reliably mean that a value will be sent on the channel, but the value may not have been sent when Stop returns.
I don't see an easy fix in the current implementation.  We can't leave the timer in timerRunning state while we unlock pp.timersLock in order to run the function.

Would it make sense to change the timer to the timerModifying state while running the callback (which should be short), and then to timerNoStatus after the callback completes?
(Or would that potentially induce starvation for a time.Ticker with a very short period?)

The same send-after-Stop problem appears to also applies to time.Ticker, which I suppose is not a surprise because they share the same underlying timer implementation.
(Code in https://play.golang.org/p/Y_Hz4xkYr07, but it doesn't reproduce there due to the Playground's  faketime patch.)

It's actually a bit more complicated than I thought.  If we leave the timer status as timerRunning (or timerModifying), then if the timer function does anything that touches the timer, it can hang.  For example, the scavenger uses a timer with a function of wakeScavenger that expects to stop the timer.  That would hang waiting for the timer to leave timerRunning status.  The netpoll code also manipulates the timer in the timer function, though I think it wouldn't cause any problems here.

Let's try to separate the discussion of semantics from implementation.
The docs say:
To ensure the channel is empty after a call to Stop, check the return value
and drain the channel. For example, assuming the program has not received
from t.C already:

    if !t.Stop() {
    	<-t.C
    }

The proposed change in semantics is to make it that no receive can ever happen after t.Stop returns. That would mean that under the assumption - "assuming the program has not received from t.C already" - t.Stop would never return false anymore. So the above code would no longer be required (and if left alone would just never execute the if body).
This would avoid the problem of people not knowing to write that fixup code or not understanding the subtlety involved. Certainly we've all confused ourselves enough just thinking through this over the years.
That's the proposed semantic change.
There are also questions about how to implement that - it's not just the easy "pull the item back out of the buffer" that I suggested before - but certainly it is possible. Let's figure out if we agree about the semantic change.
(Another side-effect would probably be that len(t.C) would always return 0, meaning the channel would appear to be unbuffered. But we've never promised buffering in the docs. The buffering is only there because I was trying to avoid blocking the timer thread. It's a hack.)

I agree that if we could change the semantics to ensure that no receive is possible after Stop, that would be preferable to both the current behavior and the originally-proposed change to only disallow a send-after-Stop.
However, I don't see any way to do that without breaking the example in https://play.golang.org/p/r77N1PfXuu5.
That program explicitly relies on the buffering behaviors of t.C: specifically, that len(t.C) becomes nonzero when the timer fires, and that the buffered value remains receivable after t.Stop(). Neither of those behaviors is strictly guaranteed by the documentation, but nor does anything in the documentation explicitly reserve them as subject to change — and they have been observable since CL 4063043 over nine(!) years ago.
Disallowing a receive after Stop must necessarily break one of those two behaviors. If we marked the buffer as non-empty but then retracted the buffered value in t.Stop(), then the program would block forever on the subsequent receive. If we instead made the channel unbuffered — or, equivalently, hooked the runtime to avoid sending to it until some goroutine is ready to receive — then the program would loop forever waiting for len(t.C) to become nonzero.
So the only way I see to make that change in semantics would be to declare that this example program is already incorrect, because it is relying on undocumented behavior regardless of the stability of that behavior. I could be wrong, but given how long this behavior has been in place I suspect that changing it would break real programs.

Do you know of any programs that call len on a timer channel?

I do not know of any specifically, but given the 9-year interval and Hyrum's law I would be surprised if they did not exist.
If we are willing to assume that such programs do not exist (or declare that they are invalid if they do exist, because the buffering behavior was never documented), then preventing the receive seems ok.

Above, we identified that one possible way that the semantic change being discussed might break code is if the code used len to poll whether the timer had gone off. We would have to make len report zero all the time, simulating an unbuffered channel. Code that depended on len sometimes being non-zero could possibly break.
My intuition was that using len on a channel is racy and almost never better than a select with a default case, so there's a decent chance that not too much code is using len. To test this hypothesis, I searched my local corpus of Go packages for length on timer channels and sifted through the results with @bcmills. We found that use of len on timer channels is (1) rare, (2) almost always incorrect, (3) when incorrect, always fixed by the new semantics.
The corpus I am using is a collection of the latest of each major version of each module listed in the Go index (index.golang.org) as of late March. There are 134,485 modules with distinct paths in my corpus. Of those, 17,021 mention time.NewTimer or time.NewTicker. Of those, 15 modules (slightly under 0.1% of the 17,021) contain code matching len\(.*\.C\) in which the len operation applies to a timer or ticker channel.
Of the 15 modules applying len to a timer or ticker channel: one is an awkward simulation of a non-blocking select, already removed in a later commit; one uses len in debug prints to monitor the ticker; and the remaining 13 are buggy.
The semantic change proposed in this issue would make all the buggy code correct, assuming we apply the same change to Reset as we've discussed for Stop. We should probably also apply the change to time.Ticker's Reset and Stop.
Use of len to simulate non-blocking select
github.com/packetzoom/logslammer
github.com/packetzoom/logslammer version v0.0.3 output/elasticsearch/elasticsearch.go (April 7, 2016)
contains the following code in output/elasticsearch/elasticsearch.go:
func readInputChannel(idx *Indexer, receiveChan chan *buffer.Event) {
	// Drain the channel only if we have room
	if idx.bulkService.NumberOfActions() < esSendBuffer {
		select {
		case ev := <-receiveChan:
			idx.index(ev)
		}
	} else {
		log.Printf("Internal Elasticsearch buffer is full, waiting")
		time.Sleep(1 * time.Second)
	}
}

...

// Loop events and publish to elasticsearch
tick := time.NewTicker(time.Duration(esFlushInterval) * time.Second)

for {
	readInputChannel(idx, receiveChan)

	if len(tick.C) > 0 || len(es.term) > 0 {
		select {
		case <-tick.C:
			idx.flush()
		case <-es.term:
			tick.Stop()
			log.Println("Elasticsearch received term signal")
			break
		}
	}
}

This code seems to be using the len checks as an alternative to a non-blocking select on those two channels. It's also worth noting that when received events are rare, the tick receive and corresponding idx.flush may be arbitrarily delayed by the blocking receive in readInputChannel. It's possible that select was meant to be non-blocking.
The semantic change proposed in this issue would make the code never process ticks, since len(tick.C) would always be zero. However, in the latest untagged commit (February 17, 2017), the test of len(tick.C) has been removed. Also, the lack of any commits in the last three years, nor even a tag of the updated code, suggests the code is unmaintained and no longer used.
Use of len for logging/debugging prints
github.com/uber/cherami-server
github.com/uber/cherami-server version v1.28.1 services/outputhost/messagecache.go (November 29, 2017) has a logPumpHealth method that logs information about the capacity and length of its ticker channel, among others:
func (msgCache *cgMsgCache) logPumpHealth() {
	logPumpHealthOnce.Do(func() {
		msgCache.lclLg.WithFields(bark.Fields{
			...
			`RedeliveryTickerCap`:         cap(msgCache.redeliveryTicker.C),
		}).Info(`cache pump health capacities`)
	})

	msgCache.lclLg.WithFields(bark.Fields{
		...
		`RedeliveryTickerLen`:         len(msgCache.redeliveryTicker.C),
	}).Info(`cache pump health`)

	lg := msgCache.lclLg
	now := common.Now()

	...
	if msgCache.lastRedeliveryTickerFull > 0 {
		lg = lg.WithField(`RedeliveryTicker`, common.UnixNanoTime(now-msgCache.lastRedeliveryTickerFull).ToSeconds())
	}

	lg.Info(`cache pump health last channel full times`)
}

And the `updatePumpHealth method does:
func (msgCache *cgMsgCache) updatePumpHealth() int {
	now := common.Now()
	fullCount := 0
	...
	if cap(msgCache.redeliveryTicker.C) <= len(msgCache.redeliveryTicker.C) {
		msgCache.lastRedeliveryTickerFull = now
		fullCount++
	}
	return fullCount
}

The logging would never trigger anymore, and the pump health update would register the channel as “full” for being unbuffered (length and capacity both 0).
However, the repository's README says that the project is “deprecated and not maintained.”
Racy use of len to drain channel after Stop
github.com/Freezerburn/go-coroutine
github.com/Freezerburn/go-coroutine v1.0.1 src/github.com/Freezerburn/coroutine/embed.go:
// Guarantee the timer channel is drained.
// Despite the docs saying to only check the return value of Stop, it's possible for Stop to return false without
// there being an item in the channel, so we also double-check if there is an item in the channel before attempting
// to drain it.
if !e.waitTimer.Stop() && len(e.waitTimer.C) > 0 {
	<-e.waitTimer.C
}
e.waitTimer.Reset(duration)
<-e.waitTimer.C

This use of len is potentially racing with the pending send that Stop did not stop. The correct code today would be to track whether e.waitTimer.C has been received from already and use that state in place of the length check. In fact, since this code is the only use of e.waitTimer, the timer will have only already fired and not been received from on the first execution of the method containing this code. Every time the method completes, the timer has expired and been read from. The first execution is different because e.waitTimer is initialized to time.NewTimer(0).
The proposed semantic change to Stop would make this code correct: on the first call, e.waitTimer.Stop would return true—the Stop prevented the zero-duration timer event from being sent. On subsequent iterations, e.waitTimer.Stop would return false—the timer event was already received by the previous call—and len would be zero, bypassing the no-longer-necessary draining code.
There is another instance of the pattern later in the file:
if !e.receiveTimer.Stop() && len(e.receiveTimer.C) > 0 {
	<-e.receiveTimer.C
}

e.receiveTimer.Reset(duration)
select {
case <-e.receiver:
case <-e.receiveTimer.C:
}

Like e.waitTimer, e.receiveTimer is initialized to time.NewTimer(0).
On top of that, the code does not record whether the select received from
e.receiveTimer.C, as it must for proper interpretation of the Stop result.
This lack of memory is partly compensated for by the racy (buggy) len check.
The same analysis applies: if the Stop guarantees to stop any future send,
then either the receive has already happened, in which case Stop returns false
and len is zero, so or the receive is prevented, in which case Stop returns true.
Either way, the code would now bypass the no-longer-necessary draining code.
The current latest commit rewrites both of those code snippets to use a helper that is different (avoiding len entirely) but still buggy:
func resetTimer(t *time.Timer, d time.Duration) {
	if !t.Stop() {
		// I've seen cases where Stop returns false, but there isn't an item in the channel, causing the receive to
		// hang forever.
		select {
		case <-t.C:
		default:
		}
	}
	t.Reset(d)
}

The same analysis applies, since a non-blocking select is just a less racy “len plus receive” operation. Removing the race between the length check and the receive did not eliminate the race with the delayed timer send. But the proposed semantic change would.
github.com/MatrixAINetwork/go-matrix
github.com/MatrixAINetwork/go-matrix v1.1.7 p2p/buckets.go (May 20, 2020):
for {
	select {
	case <-timeoutTimer.C:
		...
		if !timeoutTimer.Stop() && len(timeoutTimer.C) > 0 {
			<-timeoutTimer.C
		}
		timeoutTimer.Reset(time.Second * 60)
	case h := <-b.blockChain:
		if !timeoutTimer.Stop() && len(timeoutTimer.C) > 0 {
			<-timeoutTimer.C
		}
		timeoutTimer.Reset(time.Second * 60)
		...
	}
}

This code is trying to make sure that each iteration of the select falls into the timeout case after 60 seconds.
For the most part it succeeds, but a receive from b.blockChain right at the moment the timer went off would fail to drain timeoutTimer.C, causing the next iteration to fall into the timeout case immediately.
Same race as in previous example; proposed semantic change applies the same fix.
github.com/cobolbaby/log-agent
github.com/cobolbaby/log-agent 71f7f9f watchdog/watchdog.go:
timer := time.NewTimer(delay)
...
for {
	select {
	case e = <-eventChan:
		...
		// timer may be not active, and fired
		if !timer.Stop() && len(timer.C) > 0 {
			<-timer.C //ctry to drain from the channel
		}
		timer.Reset(delay)
	case <-timer.C:
		...
		return
	}
}

Same race; same fix.
github.com/dcarbone/go-cacheman
github.com/dcarbone/go-cacheman v1.1.2 key_manager.go:
if !lifespan.Stop() && len(lifespan.C) > 0 {
	<-lifespan.C
}
lifespan.Reset(km.idleTTL)

Same race; same fix (appears four times in file).
github.com/myENA/consultant/v2
github.com/myENA/consultant/v2 v2.1.1 service.go:
if !refreshTimer.Stop() && len(refreshTimer.C) > 0 {
	<-refreshTimer.C
}
refreshTimer.Reset(ms.refreshInterval)

Same race; same fix (appears three times in file).
github.com/smartcontractkit/chainlink
github.com/smartcontractkit/chainlink v0.7.8 core/services/fluxmonitor/flux_monitor.go:
// stopTimer stops and clears the timer as suggested by the documentation.
func stopTimer(arg *time.Timer) {
	if !arg.Stop() && len(arg.C) > 0 {
		// Residual events are the timer's channel and need to be cleared.
		//
		// Refer to timer.Stop's documentation or
		// https://developpaper.com/detailed-explanation-of-the-trap-of-timer-in-golang/
		<-arg.C
	}
}

Same race; same fix. This is of course not the code suggested by the documentation, although it does match the (incorrect) linked blog post.
This code was removed without comment in v0.8.0.
github.com/vntchain/go-vnt
github.com/vntchain/go-vnt v0.6.4-alpha.6 producer/worker.go:
// The stop command may be happen when the round timer is timeout but not deal with
// the timeout event, so cleaning the channel of roundTimer is needed.
if false == self.roundTimer.Stop() && len(self.roundTimer.C) > 0 {
	<-self.roundTimer.C
	log.Warn("worker.roundTimer.C still has a expired event, now has been cleaned")
}

Same race; same fix.
github.com/eBay/akutan
github.com/eBay/akutan 9a750f2 src/github.com/ebay/akutan/util/clocks/wall.go:
timer.Stop()
for len(timer.C) > 0 {
	<-timer.C
}
...
timer.Reset(wake.Sub(Wall.Now()))

Same race; same fix.
github.com/piotrnar/gocoin
github.com/piotrnar/gocoin 820d7ad client/main.go:
SaveBlockChain.Stop()
for len(SaveBlockChain.C) > 0 {
	<-SaveBlockChain.C
}
if common.BlockChainSynchronized {
	SaveBlockChain.Reset(SaveBlockChainAfter)
} else {
	SaveBlockChain.Reset(SaveBlockChainAfterNoSync)
}

Same race; same fix.
Racy use of len to drain channel before Reset
github.com/qlcchain/go-qlc
github.com/qlcchain/go-qlc v1.3.5 p2p/sync.go:
if len(ss.pullTimer.C) > 0 {
	<-ss.pullTimer.C
}
ss.pullTimer.Reset(pullReqTimeOut)

This is the usual pattern from the previous section, except there is no call to Stop,
so the receives are racing against an unstopped timer instead of the dying gasps of a stopped timer. But the race is the same.
If we change Reset to have the same guarantee as Stop, namely that no  send from the old timer setting (before the Reset) can complete after Reset returns, then a plain call to Reset without Stop like in this code becomes correct, even without the if statement. With the proposed change, the if body would never execute.
Racy use of len to drain channel after Reset
github.com/chenjie199234/Corelib
github.com/chenjie199234/Corelib 2d8c16542cbe logger/logger.go:
for {
	select {
	case <-tmer.C:
		...
		tmer.Reset(500 * time.Millisecond)
		if len(tmer.C) > 0 {
			<-tmer.C
		}
	case <-l.update:
		...
		tmer.Reset(500 * time.Millisecond)
		if len(tmer.C) > 0 {
			<-tmer.C
		}
	case <-l.refresh:
		...
	}
}

This is like the previous example but the draining happens after Reset, making it race with the newly reset timer. A bad scheduling pause that introduced a half-second delay in goroutine execution between the timer being reset and the draining would cause a legitimate timer event to be discarded.
This entire package was removed on April 20.
Racy use of len to drain channel without Stop/Reset
github.com/indeedsecurity/carbonbeat
github.com/indeedsecurity/carbonbeat v1.0.0 app/carbonbeat.go:
ticker := time.NewTicker(bt.config.Period)
for {
	select {
	case <-bt.done:
		...
		return nil
	case <-ticker.C:
		//Remove all ticks from the ticker channel, do not "catch up"
		for len(ticker.C) > 0 {
			<-ticker.C
		}
	}
	...
}

Strictly speaking, this code is not wrong, but it is also not useful.
The ticker channel has a buffer of length 1.
In the instant after the receive just completed, the buffer is almost certainly empty.
The check is racing with the next send, but very unlikely to lose that race.
Changing the len to always return 0 will not have any discernible impact
on this code.
github.com/indeedsecurity/carbonbeat/v2
github.com/indeedsecurity/carbonbeat/v2 v2.0.2 app/carbonbeat.go contains the same code.

For what it's worth, seeing all that buggy code as evidence of people struggling to use the current t.Stop and t.Reset correctly in single-goroutine use cases only makes me that much more convinced we should try the proposed change.

I think this is an excellent idea and I'd bet that I've written at least one piece of code which lacks, but needs, the fixup code.

Is this actually the same issue as this old one? https://github.com/golang/go/issues/11513

@rogpeppe, yes it certainly subsumes that one. The example I gave there in https://github.com/golang/go/issues/11513#issuecomment-150332714 would definitely change but after seeing real uses, I think more code will be fixed than would break. It can be an early in cycle change.
Also, in that comment I said it's not the library's job to "throw away values already sent on the channel". The fix I'm suggesting above makes the channel (indistinguishable from) unbuffered instead, so there are no values "already sent".

Based on the discussion above, this sounds like a likely accept.
One possible implementation would be:

Find a bit in the channel struct to mark timer channels.
Stop inlining chanlen/chancap.
Make chanlen/chancap return 0 for timer channels even though the representation has buffer size 1.
In Stop/Reset, clear the buffer if there's something in it.

There are other more involved implementations (see for example #8898), but this simple change seems like the shortest path to the semantics we've been discussing.

No change in consensus, so accepting.

Looks like this may happen for Go 1.23, finally.
In the discussion above https://github.com/golang/go/issues/37196#issuecomment-638344744 I said the channel would "appear to be unbuffered", but I don't think I realized at the time (or I forgot) that that's literally the entire semantic change: timer channels will now be synchronous aka unbuffered. All the simplification follows from that. (The implementation is more subtle, including a hidden buffer as an optimization, but the semantic effect is simply that timer channels will now behave as if unbuffered.)
For a graceful rollout, this change and the change for #8898 can be disabled by GODEBUG=asynctimerchan=1.

Just found this thread while trying to track down a test flake - the test was trying to drain the channel with a <-timer.C but also provided a default: flag which caused the old event to fail to be read. I am glad that the behavior here is changing to make it more difficult to do the subtly wrong thing.

With tip, the finalizer of a timer will not get executed. Is it intended?
package main

import "time"
import "runtime"

func main() {
	timer := time.NewTimer(time.Second)
	runtime.SetFinalizer(timer, func(c *time.Timer){
		println("done")
	})
	timer.Stop()
	runtime.GC()
	time.Sleep(time.Second)
}

$ gotv 1.22. run main.go
[Run]: $HOME/.cache/gotv/tag_go1.22.1/bin/go run main.go
done
$ gotv :tip run main.go
[Run]: $HOME/.cache/gotv/bra_master/bin/go run main.go
$

BTW, since Go 1.23, does the Stop method of a Timer still need to be called to make the Timer collectable as earlier as possible?

https://go-review.googlesource.com/c/go/+/512355#:~:text=This CL fixes,be GC'ed immediately.

@go101 The finalizer change sounds like a bug to me.  Please open a new issue for that.  Thanks.

@ianlancetaylor I'm not sure whether or not it is a bug, because the comment in the PR mentions a Timer object might be not allocated on heap, Anyway, I created the issue.

Thanks for creating the issue.  Seems to me it is a bug either in the implementation or in the documentation.

With this change, I'm not sure if it will be possible for fake clocks to be used for deterministic tests and behave similarly to the stdlib timer methods.
Given some production code, say:
func delayedPush(clock clock.Clock) {
  c := clock.Timer(time.Second)
  <-c
  push()
}

And the following test:
func TestDelayedPush(t *testing.T) {
	fake := clock.NewFake()
	go delayedPush(fake)

	fake.Advance(time.Second)
	if !pushed {
		t.Errorf("expected push")
	}
}

This test is flaky: it passes if the background goroutine has created the timer before the fake advances time, but fails otherwise since. This is a really common issue so tests often use runtime.Gosched() or time.Sleep(...) to work around these, and while that reduces the likelihood of failure, it can still occur -- it's not fully deterministic.
This problem can be solved with fakes that support blocking until the timer is created, e.g.,BlockUntil,
func TestDelayedPush(t *testing.T) {
	fake := clock.NewFake()
	go delayedPush(fake)

	fake.BlockUntil(1) // wait for background Timer call
	fake.Advance(time.Second)
	if !pushed {
		t.Errorf("expected push")
	}
}

Prior to this change, since the channel was buffered, the Advance would write to the channel regardless of whether the background delayedPush goroutine was waiting on the channel or not. With this change, assuming the fake behaves consistently with the stdlib (non-blocking write to an unbuffered channel), then the test is flaky again: it passes if the background goroutine is reading from the channel, otherwise, the write is dropped, and the test fails.
I'm currently working on a fake clock library, primarily to help with writing deterministic, non-flaky tests, and with this change, I'm not sure that'll be possible within the current API surface.

The code that uses the timers shouldn't care whether the channel is buffered or not.  I don't see why a fake clock library would have to use an unbuffered channel.
Please see #67434 for some recent ideas on how to test timers and the like.

The fake can use an unbuffered channel, but it's behavior will not be able to match the stdlib:

len and cap would return different values. Based on Russ's analysis above, I think this is probably OK.
Stop will behave differently since it can't unsend values like the stdlib.

I was hoping to build a fake that matches the stdlib behavior closely for high fidelity testing.
In this case, it's not a huge issue since the new stdlib is less error-prone, and continues to work with code written against the previous model.
After reading the time PR more closely, it's likely that the fake can emulate the stdlib more closely by using the expensive approach that the change emulates -- use a separate goroutine to write to the channel, cancelling it when Stop is called, etc.

func delayedPush(clock clock.Clock) {
  c := clock.Timer(time.Second)
  <-c
  push()
}

To me it looks like test for this code will be racy in any case - this just can't be solved by doing something with timers, because all you can get as result is sync with <-c line, but not push() line, while test actually needs sync with push() line.


'a' adds bottom padding on row

.Example
[cols="3,4"]
|===
.3+|text
|- |- |-

|text |-

a|interpreted text |-
a|interpreted text |-
|===

[cols="3,4a"]
|===
.3+|text
|- |- |-

|text |-
|text |-
|===

Creates

As far as i can tell, 'a' adds bottom padding to each row, to the first one with multiple rows and if applied globally to each new row.
While rows in asciidoctor (html) all render the same.
Is this intended?

This is a known issue that is being addressed by #1515.


Add Aditya Ranjan to Contributors list

Hey, There
This is my first contribution.

Hey, There
This is my first contribution.

done @Aditya-619


Cleanup

the comment is still there and make sure to run go test again after the gofmt

Took a look at the code that was deleted - the deletion of the Kron web UI is good since it is not used (this is what I thought you were referring to before). Not sure about the deletion of exec/suspend/unsuspend because they would work in general for someone who wants to use ctl to manipulate the cronjobs. I'd advise to keep them and just rename package "kron" to just "cronjob"


regex as re replacement

As highlighted in this article backtracking is problematic - standard python engine is still prone to being stuck in endless backtracking loops.
https://pypi.org/project/regex/ might be the better alternative

As an alternative https://pypi.org/project/timeout-decorator/ might just provide an escape from endless backtracking


script file extension is not necessary

[ x] I have read freeCodeCamp's contribution guidelines.
[ x] My pull request has a descriptive title (not a vague title like Update index.md)
[x ] My pull request targets the master branch of freeCodeCamp.
[x ] None of my changes are plagiarized from another source without proper attribution.
[x ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

just create file without extensions


.

The developer guide has already been moved to to content/en/docs/guides/contributor-guides. It was inadvertently added in  PR-92 and should be deleted here.

/assign @tliron

Good catch.
The mockery related description is missing from the content/en/docs/guides/contributor-guides version. Is mockery not used anymore?

Can you add a bit more descriptive name to the pr?

/assign @liamfallon

Good catch. The mockery related description is missing from the content/en/docs/guides/contributor-guides version. Is mockery not used anymore?

I've just learned from @kispaljr that mockery is still used, so I would propose to keep the text about it. I do not know and why how that of the guide was removed.

Good catch. The mockery related description is missing from the content/en/docs/guides/contributor-guides version. Is mockery not used anymore?

Well it was my error that it was included. Yes Mockery is being used but I checked in a preliminary version of Mockery instructions that I'm working on. It's not ready to be merged yet.

Can you add a bit more descriptive name to the pr?

Done

Good catch. The mockery related description is missing from the content/en/docs/guides/contributor-guides version. Is mockery not used anymore?

I've just learned from @kispaljr that mockery is still used but I could not find the referred file even in the history (git reflog --diff-filter D --pretty="format:" --name-only | grep mockery) what I think the reason why the section referring to it was removed.
All in all it is ok to delete the file.

I will add the Mockery description in a few days when I get a chance to add/edit the text properly.

/approve


Fix the behavior of focus selection in bezier editor

Fixes #66924
Avoid zooming when infinite zooming may occur. CC @Razoric480

Thanks!


Disable code generation for model-only modules

Since the introduction of spine.assembleModel(), the model-only Gradle projects generated Java code in order to satisfy the internal API of the bootstrap plugin.
This PR disables the code generation activated by spine.assembleModel().

@armiol, PTAL>


Admin Template: Preview button

When you create or Edit a Template, the Preview button is not useful.

See also #481 for similar behavior to fix.

I don't understand the issue. It's super useful !

I didn't understand the purpose when I was editing a Widget__ImageWidget template.

I use this issue for another problem then:
I created a tenant called 'agency'.
When I click on the preview button, it opens http://localhost:2918/agency/Orchard.Templates/Preview/Index and a Bad Request erro happens :
Bad Request - Request Too Long

HTTP Error 400. The size of the request headers is too long.

and any url returns this error (on main site or tenant).

Issue with the cookies, I still need to clean them, but looks like they are too big on your system

If you are using IIS it might be limited to 16KB

I still have this error when I edit the template Content__LandingPage of TheAgencyTheme in the admin after an install of OrchardCore as a nuget package.


UTXO with multiple inscriptions error shows when only one inscribed sat is present - API issue?

This error is expected when an output has multiple inscriptions https://github.com/hirosystems/wallet/issues/3484. In this case users are getting the error when that is not the case and it prevents sending. Four users reported this today and I see it myself on an UTXO that I know to have only one inscribed sat.
I do not see signs of an inaccessible API in the console although that does look like it could be the cause.

Having the same issue. There is certainly enough bitcoin in the wallet. Also each inscription was sent separately to hiro so they all cannot be on the same UTXO.

Same issue. It worked the first time we inscribed + sent an ordinal. But then it failed the next 10 times.

We did a hacky fix like this.
Before:
if (numInscriptionsOnUtxo !== 1) {         setShowError('Sending inscription from utxo with multiple inscriptions is unsupported');         return;  }
After
if (numInscriptionsOnUtxo > 1) {         setShowError('Sending inscription from utxo with multiple inscriptions is unsupported');         return;  }

https://github.com/hirosystems/wallet/pull/3621#issuecomment-1529568053


Remove specialist-frontend reference from docs

format_namedoesn’t appear to be used by government-frontend or govuk_navigation_helpers
specialist-frontend is being retired.

Thanks @fofr 👍


Update L000575.yaml

Removed recaptcha to reflect form

Hi Amy -- I have some questions congress forms API -- would you be able to help out?
If so, what is the best way to reach you?
Thanks!
kp


The master branch, like the new recoil crosshair


Fix: Allow interactions with elements under the gradient overlay

Hi,
Thanks for creating react-fast-marquee, it's been really useful in my projects. I noticed a small issue when I have links around my logos - they can't be interacted with under the gradient overlay. I've been overriding the library class to add pointer-events: none; and touch-action: none; to the CSS which solves the problem. Thought this tweak could be useful for others too.
Cheers!

Thanks, added in 1.6.2!


Obsolete instructions in CONTRIBUTING.md, pt. III, node_package/scripts/*

[Sorry for creating a number of small issues.   Is that way more efficient for you or we should merge everything to a single issue and work there?]
Beginning with https://github.com/shakacode/react_on_rails/blob/master/CONTRIBUTING.md#run-most-tests-and-linting, there are three scripts mentioned, node_package/scripts/ci, node_package/scripts/build and node_package/scripts/lint, all of them were removed in 948697ccef37320.
It looks like the first one could be just removed.  The second one is more interesting:

If you change the JS code for react-on-rails, you need to run node_package/scripts/build. Since the react-on-rails package should be sym linked, you don't have to npm i react-on-rails after every change.

Either this paragraph could be completely removed because it's now handled automatically by npm install --save<EMAIL_ADDRESS>or I'm missing something.    Am I?
Thank you,

@squadette Please provide a PR with your suggestions! Sounds great! Thanks for your participation! AWESOME!

@squadette Feel free to close the other issues and put them all into this one issue or PR.

committed an update! thanks for pointing this out!


Type RequestT may be intimidating

Currently, RequestT[U[_], T, -R] takes three type parameters. One of them is a phantom type (U[_]), and another one models the “backend capabilities required by the request or response” (R).
This is very powerful, but in my opinion, it exposes unnecessary complexity for users interested in using the SimpleHttpClient added in #1545, for instance. I wonder if we could also provide a Request type specific to synchronous backends (so, without a notion of capabilities), and a builder system to differentiate between a partial request and a complete request (to avoid the need for a phantom type).
I believe that would expose a type that would be easier to work with for people only interested in doing synchronous requests on the JVM.
Here is an (untested) idea:
trait RequestBuilder[A] extends RequestT[Empty, A, Any] {

  def cookie(n: String, v: String): RequestBuilder[A]
  def contentType(ct: String): RequestBuilder[A]
  def header(k: String, v: String): RequestBuilder[A]
  def body(...): SyncRequestBuilder[A]
  def response[B](rb: ResponseAs[B, Any]): RequestBuilder[B]
  // ...

  // “finalizers”
  def get(uri: Uri): Request[A]
  def post(uri: Uri): Request[A]
  // ...

}

trait Request[A] extends RequestT[Identity, A, Any] {
  def send(backend: SttpBackend[Identity, Any]): Response[A]
}

I wonder if the backend parameter could even be omitted in the send method of Request, if the request was created by the backend itself:
val client = SimpleHttpClient()
val request =
  client.basicRequest
    .body("Hello, world!")
    .post(uri"https://httpbin.org/post?hello=world")
val response = request.send()

I agree. We should never expose RequestT. it's a scary type that requires knowledge of Monad transformers to fully understand. An http client should never demand that level of knowledge, unless it is part of a category theory inspired library where such knowledge is a prerequisite.

@odersky I think there's a misunderstanding, there are no monad transformers involved at all :) RequestT stands for "RequestTemplate" and has been there since sttp v1 I think. I doubt we'll be able not to expose it as it's the central datastructre in sttp.
There are two aliases which are often used, though:
  /** A [[RequestT]] without the method & uri specified (which cannot yet be sent).  */
  type PartialRequest[T, -R] = RequestT[Empty, T, R]

  /** A [[RequestT]] with the method & uri specified. Such a request can be sent. */
  type Request[T, -R] = RequestT[Identity, T, R]

@julienrf Request is already taken by an alias to RequestT. We can try e.g. SimpleRequest, but keeping in mind:

we have to maintain binary compatibility
I wouldn't want the "simple" API to diverge to much from the "normal" one. We'll end up maintaining two libraries and two APIs inside of one binary - not something I'd like to do.

Note that synchronous requests can also leverage capabilities. Currently the default backend doesn't support any, but I hope to implement websocket support at some point in time. Streaming is also not out of the question, I think we could accept RS publishers as a body inside an otherwise synchronous request.
The whole point of RequestT is not to duplicate all the builder methods which allows describing the request. Whether this was a good decision might be up for debate of course, but it's there since sttp v1 and if at all, we could consider changing it in sttp v4. But providing a hybrid in a 3-point release isn't probably a good idea.
As for creating the request from the backend - again, it's a different API, which would yield a different library. We already have too many ways of sending requests (request.send(backend); backend.send(request); simpleHttpClient.send(request)). Adding yet another one would be only confusing. Plus, I don't think that's really doable, if we want to keep the data structure which describes the request the same for "synchronous"/"simple" and "normal" cases.

@adamw Ah, I misunderstood then. When I see an AbcT type that takes an higher-kinded type I always think Monad transformer, since the naming convention is so pervasive.
For the Scala toolkit: I think it's a fairly big step to make a library part of it. So doing changes that need a major release seems reasonable to me.

@odersky I think I came up with the name quite long ago when I wasn't that familiar with the monad-related naming conventions :)
A major release with an improved API is of course possible, and suggestions are very welcome. However, I'd like to keep a single API, which works the same with synchronous & async requests. I think it's only an advantage if a library from the toolkit allows you to work with the same (or very similar) API in the "simple" cases and when using any of the effects used in Scala (Future, cats, ZIO). Looking at sonatype's stats, currently the vast majority of sttp's users use it with some kind of async backend - so it's not a public we should overlook :)

Right now when a request is being constructed with basicRequest, the RequestT type does leak to the user in suggestions and types of expressions. I agree that it would be great to avoid that. If we were able to create some simple request builder that did not expose these types, I think it could lead to less confusion for users.

There are two aliases which are often used, though:
  /** A [[RequestT]] without the method & uri specified (which cannot yet be sent).  */
  type PartialRequest[T, -R] = RequestT[Empty, T, R]

  /** A [[RequestT]] with the method & uri specified. Such a request can be sent. */
  type Request[T, -R] = RequestT[Identity, T, R]

These aliases precisely expose the full RequestT type to the end users since they are “transparent” aliases.

Request is already taken by an alias to RequestT. We can try e.g. SimpleRequest, but keeping in mind:
1. we have to maintain binary compatibility

2. I wouldn't want the "simple" API to diverge to much from the "normal" one. We'll end up maintaining two libraries and two APIs inside of one binary - not something I'd like to do.

Note that synchronous requests can also leverage capabilities. Currently the default backend doesn't support any, but I hope to implement websocket support at some point in time. Streaming is also not out of the question, I think we could accept RS publishers as a body inside an otherwise synchronous request.
The whole point of RequestT is not to duplicate all the builder methods which allows describing the request. Whether this was a good decision might be up for debate of course, but it's there since sttp v1 and if at all, we could consider changing it in sttp v4. But providing a hybrid in a 3-point release isn't probably a good idea.
As for creating the request from the backend - again, it's a different API, which would yield a different library. We already have too many ways of sending requests (request.send(backend); backend.send(request); simpleHttpClient.send(request)). Adding yet another one would be only confusing. Plus, I don't think that's really doable, if we want to keep the data structure which describes the request the same for "synchronous"/"simple" and "normal" cases.

Thank you for the detailed explanation. I understand the concerns about binary compatibility and code duplication.
Indeed, what I suggest is to have another type Request that would be specific to the SimpleHttpClient. That would indeed be another API to maintain, given the current design of sttp.
I see value in keeping the ability to describe requests independently of a specific backend implementation (I use that in endpoints4s, for instance). However, I guess the typical workflow with sttp, for end-users, is to pick just one backend and send all their requests through that backend. This is why I would like to investigate whether it is possible to “optimize” the API in that direction. But my initial assumption might be wrong?
I think it is possible to create a new type SimpleHttpClient.Request[A] (along with SimpleHttpClient.RequestBuilder[A]), as I described above. Would you be open to that?

I would try to avoid creating a parallel API if possible. The whole point of sttp is that you create a data structure describing the request, and then you can send it using any backend (as long as it has the required capabilities).
If we were to create a separate synchronous-only API, then I think it would make more sense to publish it as a separate library, with its own lifecycle etc.
Another thing is all the integrations - even the most basic ones, redirects, observability, custom retry backends etc. - they all use the current API and would have to be duplicated. Not something I'd like to maintain :)
But that doesn't mean that some improved type hierarchy, maybe requiring a binary-incompatible change, which gives better synchronous requests support is not possible. However first, I'd like to gather some information if the RequestT is indeed a problem. One data point that I have, is that on the support channels that I participate in (gitter, issues), I think only once or twice there was a question about the type aliases and type parameters. Of course, my memory could be incomplete, or beginners might be discouraged and simply not ask.
Still, I'd like to run a more thorough process to see what are the problems with the current design before jumping to solutions :). But that's probably earliest in December.

Closing as this is implemented in sttp4, thanks for the comments!


Update logback-classic to 1.2.9

Updates ch.qos.logback:logback-classic from 1.2.4 to 1.2.9.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "ch.qos.logback", artifactId = "logback-classic" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #252.


Add file path option to follow include in Tokenizer

This is to allow the tokenizer to cope with relative include paths that aren't in quote marks, it isn't required by the standard and isn't always in generated A2Ls (depending on software)

Thanks for your pull request.
I agree, the standard does allow for unquoted filenames, which I had not considered until now.
I pulled your change into my local branch and ran cargo test. This resulted in several errors:
failures:

---- tokenizer::tests::tokenize_a2l_number stdout ----
thread 'tokenizer::tests::tokenize_a2l_number' panicked at 'called `Option::unwrap()` on a `None` value', src\tokenizer.rs:135:33

---- tokenizer::tests::tokenize_a2l_comment stdout ----
thread 'tokenizer::tests::tokenize_a2l_comment' panicked at 'called `Option::unwrap()` on a `None` value', src\tokenizer.rs:135:33

---- parser::tests::parsing_numbers_test stdout ----
thread 'parser::tests::parsing_numbers_test' panicked at 'called `Option::unwrap()` on a `None` value', src\tokenizer.rs:135:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- tokenizer::tests::tokenize_a2l_item stdout ----
thread 'tokenizer::tests::tokenize_a2l_item' panicked at 'called `Option::unwrap()` on a `None` value', src\tokenizer.rs:135:33

---- tokenizer::tests::tokenize_skip_a2ml stdout ----
thread 'tokenizer::tests::tokenize_skip_a2ml' panicked at 'called `Option::unwrap()` on a `None` value', src\tokenizer.rs:135:33

---- tokenizer::tests::tokenize_string_with_backslash stdout ----
thread 'tokenizer::tests::tokenize_string_with_backslash' panicked at 'called `Option::unwrap()` on a `None` value', src\tokenizer.rs:135:33

failures:
    parser::tests::parsing_numbers_test
    tokenizer::tests::tokenize_a2l_comment
    tokenizer::tests::tokenize_a2l_item
    tokenizer::tests::tokenize_a2l_number
    tokenizer::tests::tokenize_skip_a2ml
    tokenizer::tests::tokenize_string_with_backslash

So it looks like your change still needs some work.
In addition to fixing your code so that it doesn't cause the other tests to fail, I would appreciate if you would also add a new test that verifies parsing of quoted and unquoted includes.

Hi,
Thanks for looking at this PR so quickly.
I've fixed it so the current tests pass and then have added a new test for reading include sections with paths for both Unix and Windows styles, both styles in quotation marks and not.
Thanks!

Looks good now - thanks for your contribution!


Set uuids on new OAuth users too to fix duplication errors

@petschekr Can we merge this

@ehsanmasdar @petschekr Don't we need to set new UUIDs for our existing users?

@illegalprime Yes we do. But we need to merge this so that the staging environment doesn't keep crashing. We can add uuids retroactively when we bump the live site to >=1.11.4


Create WEKEO DIAS drivers

Original report by Oyono (Bitbucket: aoyono, GitHub: aoyono).

https://www.wekeo.eu/

Update CSW plugin (see if #94 is needed) and finalize wekeo provider integration

Currently, search with wekeo is implemented with the CSW search plugin.
Some research has shown that:

The CSW endpoint offered by wekeo only allows to get access to the collections metadata, not to the products themselves. This request, for instance, shows that wekeo offers 232 collections.
wekeo offers now a REST Api called Harmonised Data Access API. It has an open-source client hda developed by the ECMWF.
Some scripts and notebooks, available online, show how to use the HDA API (here and here) The functions used in the 2nd notebook can be found in wekeo's Jupyter Hub (Sign in -> Dashboard -> JupyterHub)
The package eo_harvest uses the HDA API of wekeo to search and download products
wekeo requires a token to access to its HDA API, once generated it is valid for 1 hour only.

Wekeo's search plugin won't rely on the CSW plugin anymore (which will still stay around), it will instead rely on the HDA API.

By the use of HDA API , in particular the querymetadata, you can see the list of parameters to use for product request. After that no metadata on a product instance is given due to the fact that this interface has for objective to standardize the request and some metadata are not available on all products (ie. CMEMS or Land)

For example, the only metada available for a given S1_SAR_GRD product is:
 {
      "downloadUri": null,
      "filename": "S1B_IW_RAW__0SDV_20200110T174650_20200110T174723_019758_0255B5_F9FC.SAFE",
      "order": null,
      "productInfo": {
        "datasetId": "EO:ESA:DAT:SENTINEL-1:SAR",
        "product": "S1B_IW_RAW__0SDV_20200110T174650_20200110T174723_019758_0255B5_F9FC.SAFE",
        "productEndDate": "2020-01-10T17:47:23.200000Z",
        "productStartDate": "2020-01-10T17:46:50.800000Z"
      },
      "size":<PHONE_NUMBER>,
      "url": "040ff724-6884-5366-ac68-eb96a78d2c4f/S1B_IW_RAW__0SDV_20200110T174650_20200110T174723_019758_0255B5_F9FC.SAFE"
    },


docs: Correct resolve conflicts argument in UPGRADE-20.0.md

Description
the pr fixes a typo in the release note
Motivation and Context
reduce users confusion.
Breaking Changes
none
How Has This Been Tested?
by comparison to code

This PR is included in version 20.1.0 :tada:


Automated cherry pick of #4123: guestnetworks: check ifname uniqueness across different networks

Cherry pick of #4123 on release/2.10.0.
#4123: guestnetworks: check ifname uniqueness across different networks

/lgtm
/approve


Unable to Build Required Kernel Modules for Container Management on Jetson Nano with Yocto

Issue: Kernel Modules Missing for Container-Management Feature in Custom Jetson Nano Yocto Image
Problem:
I am building a custom Linux image for the Jetson Nano using Yocto with the linux-tegra kernel. During the build process, I encounter the following error:

The error is related to the missing kernel modules required for the container-management feature:

kernel-module-dm-thin-pool (for Device Mapper thin provisioning)

kernel-module-xt-masquerade (for Netfilter NAT functionality)

Yocto Layers in Use:
/layers/meta /layers/meta-poky /layers/meta-leda /layers/meta-leda/meta-leda-bsp /layers/meta-leda/meta-leda-components /layers/meta-leda/meta-leda-distro /layers/meta-rauc /layers/meta-kanto /layers/meta-virtualization /layers/meta-oe /layers/meta-filesystems /layers/meta-python /layers/meta-networking /layers/meta-tegra

Kernel Configuration:
The custom kernel configuration for linux-tegra (located at meta-tegra/recipes-kernel/linux/linux-tegra-4.9/custom-defconfig) includes:

CONFIG_DM_THIN_PROVISIONING=m
CONFIG_IP_NF_TARGET_MASQUERADE=m

These configurations should enable the required modules as loadable kernel modules (m).

Container-Management Recipe:
The recipe for container-management (found in meta-kanto/recipes-containers/container-management/container-management_git.bb) has the following dependency:
RDEPENDS:${PN} += "kernel-module-dm-thin-pool kernel-module-xt-masquerade"

Expected Behavior:
The kernel modules dm-thin-pool and xt-masquerade should be included in the image, and the build should succeed without errors related to missing kernel modules.
Current Behavior:
The build fails with errors about missing kernel modules (kernel-module-dm-thin-pool and kernel-module-xt-masquerade) required by the container-management package.
Any guidance on resolving this issue would be greatly appreciated.
Environment:

Yocto version: [insert Yocto version]
Jetson Nano
Custom Linux kernel (linux-tegra)

Start with checking to see if your kernel config modifications actually worked. You can examine the generated .config in the kernel build tree. If you don't see the settings the way you want them, examine the configuration logs to see why they didn't take.
If the settings are =y in the generated config, instead of =m, then the drivers are built into the kernel, rather than being separate modules, and the RDEPENDS in that recipe needs fixing - kernel module needs are usually set with RRECOMMENDS instead of RDEPENDS to allow for the possibility that needed drivers are built-in.
If the settings are =m, then packages for those drivers should have been generated, and should show up under tmp/deploy/rpm (assuming you're using the default RPM packaging) to available to the image recipe. You might want to look into the kernel makefiles to make sure that the driver names corresponding to those config setting actually match up with what the recipe is expecting.  The kernel for the TX1/TX2 is really old now, so there's a chance that drivers got renamed in later versions of the kernel and the recipe is trying to use the new names.


Default workflow archiving module

Implements issue https://github.com/Netflix/conductor/issues/1563

Pull Request Test Coverage Report for Build 3785

10 of 13 (76.92%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 69.982%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

contribs/src/main/java/com/netflix/conductor/contribs/ArchivingWorkflowModule.java
0
3
0.0%

Totals

Change from base Build 3755:
0.006%

Covered Lines:
11426

Relevant Lines:
16327

💛  - Coveralls

Review comments were applied


Type on line 141

Good luck with this project.

Hi @idkjs, a good catch & thanks for the pull request! But we are unable to merge it directly here as the documents are generated by using Couscous and the docs are managed in a separate branch Quorra-docs. So the actual changes need to be in the Docs repo!
We apologise for the confusion, and will update the repo with more details on contributing to the Docs etc.
Thanks!


Add PHPUnit 4.8 to require-dev

As mentioned in reactphp/react#354
Added phpunit 4.8 to require-dev section of composer.json
Modified travisci config to use local phpunit.

@clue completed as requested


connection to smsc with double tcp sesion?

Python 3.7
Naz 0.7.4
socket_timeout = 30.0
Client performs connection to smsc...

Are packets 1 and 4 establish 2 tcp-sessions?
And bind_transceiver is sent across second session on 30 seconds after starting...

What is happening here is;

when the naz command line app starts, we shedule about 4 different coroutines in the python eventloop;
https://github.com/komuw/naz/blob/cc6ce6472f9622e7c317fb4309cbf66bf60d15e1/cli/cli.py#L107-L112

Of note, is the connect() and tranceiver_bind() coroutines.  Since those coroutines are scheduled to run concurrently, it so happens that the tranceiver_bind() coroutine can run before the connect() coroutine has finished.

If that happens, tranceiver_bind() will fail. If it fails, then naz needs to schedule another attempt to bind to the SMSC. Since the previous bind had failed, it makes sense to wait for a while before issuing another bind request.

How long does naz wait before sending another bind request?  currently naz waits for a duration equal to naz.Client.socket_timeout. By default socket_timeout is 30seconds. ;
https://github.com/komuw/naz/blob/cc6ce6472f9622e7c317fb4309cbf66bf60d15e1/naz/client.py#L1803-L1816

When issuing the bind request, naz also does a tcp connection because the previous bind may have failed because of tcp failure.

So, it would be good to have  tranceiver_bind()  coroutine wait for the connect() coroutine to finish first before running. But the implementation to do that would be overkill and I do not think the effort is worth the gain

How long does naz wait before sending another bind request? currently naz waits for a duration equal to naz.Client.socket_timeout. By default socket_timeout is 30seconds.

Do note that this is an implementation detail and is likely to change. ie, users should not rely on this behaviour.

Why can not to use the first TCP-session (after 30 sec)?
Why is impoissible to kill unused TCP-session ?

The first (simplest, but not beautiful) step is remove client.connect() and client.tranceiver_bind()
tasks = asyncio.gather(
#client.connect(),
#client.tranceiver_bind(),
client.dequeue_messages(),
client.receive_data(),
client.enquire_link()
)
re_establish_conn_bind() can perform tcp-connection and bind_transciever......

I do not consider this to be a major problem that needs to be solved.
It is an annoyance, but an annoyance that I'm happy to live with.
Unless it turns out that there is a serious bug hiding somewhere underneath, I'm going to close this issue.


Electron updates

Description of changes
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I did not test the outputs, but I did throw some compute at it, if that's of any help.
I can also provide the outputs or if you tell me what to test I can try to that as well :)
Result of nixpkgs-review pr 287045 run on x86_64-linux 1

2 packages failed to build:

redisinsight
sharedown

53 packages built:

authy
bilibili
bitwarden
bruno
camunda-modeler
deltachat-desktop
drawio
drawio-headless
electron (electron_28)
electron_26
electron_27
element-desktop
element-desktop-wayland
freetube
headset
heroic
heroic-unwrapped
itch
jitsi-meet-electron
logseq
mattermost-desktop
micropad
morgen
nix-tour
open-stage-control
pandoc-drawio-filter
pandoc-drawio-filter.dist
pocket-casts
podman-desktop
pritunl-client
python311Packages.mkdocs-drawio-exporter
python311Packages.mkdocs-drawio-exporter.dist
python312Packages.mkdocs-drawio-exporter
python312Packages.mkdocs-drawio-exporter.dist
r2modman
revolt-desktop
standardnotes
stretchly
super-productivity
teams-for-linux
terra-station
thedesk
threema-desktop
tutanota-desktop
uhk-agent
uhk-udev-rules
uivonim
vesktop
vieb
webcord
webcord-vencord
webtorrent_desktop
youtube-music

# git describe --abbrev=40
24.05-pre-30125-g4fd34a1ef73f770af436e338752a689114b62d09


Support for Common Expression Language (CEL)

Add support for Common Expression Language (CEL) as alternative for all selectors currently based on tidwall/gjson, including:

NamedPatterns
ValueOrSelector and NamedValuesOrSelectors
Plain identity selector

CEL as a superset of gjson-powered Authorino features
TBC – All gjson-powered features supported in Authorino can be modeled and supported in CEL. Special attention to be given to gjson's modifiers and custom ones introduced by Authorino.
Should CEL paths become the standard?
To keep backward compatibility, maybe the paths specified in CEL can be prefixed with cel:, until slowly transitioned to become the default, when either we can drop support to gjson or introduce a prefix for it to keep being supported.

wrt modifiers, I think these can be custom functions we add to the cel interpreter. I'd suggest we keep these align across the "runtimes" tho, i.e. have them being kuadrant-wide extensions (wasm-shim, limitador, ...)


Question: Custom-ish header (x-auth-psk)

I'm trying to add an X-Auth-PSK header to a reqwest Request, but it doesn't seem to be working properly (403 - but it works when I do it in python, it's definitely this request).
Relevant code:
headers.insert(
    reqwest::header::HeaderName::from_static("x-auth-psk"),
    reqwest::header::HeaderValue::from_static("qwerty"),
);

I've tried various other methods (from_str, from_lowercase etc), but none of them would compile.
Full code:
pub fn mute() {
    let raw_payload = r#"{
        "method": "setAudioMute",
        "id": 601,
        "params": [{"status": true}],
        "version": "1.0"
        }"#;

    let payload: serde_json::Value = serde_json::from_str(raw_payload).unwrap();

    let mut headers = reqwest::header::HeaderMap::new();

    headers.insert(
        reqwest::header::CONTENT_TYPE,
        reqwest::header::HeaderValue::from_static("application/json"),
    );

    headers.insert(
        reqwest::header::HeaderName::from_static("x-auth-psk"),
        reqwest::header::HeaderValue::from_static("qwerty"),
    );

    let client = reqwest::Client::new();

    let res = client
        .post("http://<IP_ADDRESS>/sony/audio")
        .json(&payload)
        .send();
    println!("{:?}", res);
    println!("{:?}", headers);
}

Output of those debug prints:
Ok(Response { url: "http://<IP_ADDRESS>/sony/audio", status: 403, headers: {"content-type": "application/json", "content-length": "169", "connection": "keep-alive"} })
{"content-type": "application/json", "x-auth-psk": "qwerty"}

It looks like you don't set those headers on the request. Try client.post(url).headers(headers).... (Also, using the json method will automatically set the json content-type).

 Sorry!


Match Scratch's script sequencing and execution semantics

Right now, Leopard's execution semantics seem to be rather simple--we step each script once per frame. This is close enough to what Scratch does in many cases, but in actuality it's a bit more complex. Scratch's logic is roughly:

Once per frame, we step all the scripts.
Then, we check if any redraws have been requested. Most blocks which cause a visual change on-stage (e.g. motion blocks, looks blocks) will request a redraw, but notably the "hide" block does not.
If no redraws have been requested, we keep stepping all the scripts until either a redraw is requested, all the scripts are done, or we've run out of time budget (75% of the frametime).

Scratch also supports "turbo mode" semantics, which fit neatly into the above logic: if turbo mode is enabled, then we don't stop when a redraw is requested, only caring about the other two conditions (scripts are done, or time budget).
The main pitfall to watch out for when implementing this is busy-waiting. Right now, there's a lot of code that yields in a loop while waiting for a promise to resolve. This is fine if we only step threads once per frame, but in the case where no redraws have been requested or we're running in turbo mode, those loops will gladly spin until we've used our time budget, eating up a bunch of CPU time.
To avoid busy-waiting, I believe we need runtime support for yielding to promises--a script waiting for a promise is placed into a "sleeping" state where it will not be stepped until the promise resolves.

Out of curiosity... busy waiting is (unfortunately) a thing in Scratch, right? The easiest tell is that just clicking a "forever" block will cause dragging around blocks in the editor to suddenly feel choppy and slow.
Can you narrow down on which circumstances of busy waiting we wish to avoid, and/or define busy waiting more particularly? Although we want to match Scratch's project behavior i.e. all execution semantics, we can (and do) differ in the implementation that "gets us there". This may be able to include avoiding certain instances of busy-waiting, but we have to be sure that the definition of busy-waiting is separate from the definition of runtime semantics. The presence or absence of any busy-wait we remove shouldn't affect project semantics.

Yes, there are still situations where Scratch will busy wait--as you mentioned, an empty "forever" block with nothing to request a redraw will do so, and I believe a "wait" block will do so as well in the absence of any redraw requests.
Scratch will not busy-wait on promises, however--threads have their own "promise wait" state that causes them to be skipped over until the promise resolves. Any thread that is itself waiting for one of those threads to finish will need to do the same--see https://github.com/scratchfoundation/scratch-vm/pull/1211, for instance.

While we're discussing promises, this feels like a good time to reference the discussion about triggers: #197 I'm not very happy with the user-facing API for triggers, and it feels like an addEventListener-inspired approach would be better. In that discussion, I created a proof of concept system that includes support for async functions and async generator functions.

I actually don't think we need async functions or generators--I'm working on an experimental runtime revamp that allows you to simply yield a promise and have the runtime automatically pause the script then resume it with the resolved value of the promise.

Oh, nice! (I believe yielding a promise is equivalent to an async generator, but I'm not 100% sure.)

It looks like the difference is that an async generator always yields promises, whereas a regular generator only yields promises if the thing being yielded is already a promise.


Github release notes for 7.2 incorrectly reference 7.1.

Github release notes for 7.2 incorrectly reference 7.1.
Upgrade Instructions
Switch your build to use Gradle 7.1 by updating your wrapper:
`./gradlew wrapper --gradle-version=7.2`

Fixed it, thanks


[nrf fromtree] dts: vendor-prefixes: Add OpenThread.io vendor prefix

Added OpenThread.io vendor prefix to enable
openthread,config dts binding for additional OpenThread configurations.
Signed-off-by: Maciej Baczmanski<EMAIL_ADDRESS>(cherry picked from commit 9748250e7295495a18da29b4aa65eaf3eafc46e1)

Will be included in Zephyr upmerge


KataPotter Kata

KataPotter

Create a package katapotter and do it.

@JoseLlorensRipolles when is your solution?

Wow I've forgot! As soon as I can! Have you worked it out yet ? @tonilopezmr

Hey @tonilopezmr I've just finished it. You can take a look at my fork (https://github.com/JoseLlorensRipolles/Katas/blob/master-java/KataPotter/src/main/java/katapotter/KataPotter.java).
What do you think about it ? I'll continue refractoring it when I have some time!

Why we do katas? To learn how to test, what it has to test, learn TDD, naming of things, and resolve problems.
You only have done the last.

I'm not sure on how to use the OO paradigm here. We can discuss it in slack. Eitherway I'll improve my code as soos as I can @tonilopezmr

It's not difficult, a book is a Book, a collection of books is a BookBasket with price, etc, etc...
Transform your thought to code.

@JoseLlorensRipolles Hey have a PR!!  to add the KataPotter !!


added Pelican static site generator in Python

[x] verified that the CMS I'm adding is still maintained.
[x] read CONTRIBUTING.md.
[x] did not generate README.md.

fixes postlight/awesome-cms#129 "Pelican static site generator could be added"

thanks @silpol !


New theme submission: Ezhil

Theme submission
Link to my theme repository: https://github.com/vividvilla/ezhil
I made sure that...

[x] the repository contains a good README.md describing my theme
[x] an open source license has been added to LICENSE.md
[x] all metadata have been added to theme.toml
[x] screenshots have been added in the images/ folder with the required dimensions
[x] in case I'm using a customized demo via the exampleSite folder that

[x] https://example.com is set as base url in exampleSite/config.{toml, yaml, json} to avoid the abuse of unused domains
[x] I tested that my theme's demo works with the content directory of gohugoio/HugoBasicExample

[x] I tested my theme against the gohugoio/HugoBasicExample

[x] I've checked the developer tools' console in my browser for error messages

[x] in case my theme is using Hugo Pipes features like toCSS and PostCSS that I have committed the /resources directory with all generated assets, for my theme to work in the basic version of Hugo

Feel free to ask questions. We're glad to help.

Hello Vivek,
thank you for sharing this minimalistic and beautiful theme with the Hugo community. Your theme should be listed soon on the themes site.
Furthermore, I'll promote your theme on Hugo's official Twitter account.
One minor issue: the url that you're using in the footer to Hugo will link to www.themes.gohugo.io/theme/ezhil/gohugo.io instead of www.gohugo.io. Please prefix this url at least with www..


New option for Faust version

We should include an option that lists the faust version and depending on which is chosen install the other dependencies like robinhood-aiokafka.

closing this issue because we always must be sticked to the latest faust version.


Support SSL options via environment vars

Perhaps this isn't the most well developed code, but it became a giant sticking point for me while on Heroku.
I worked with Heroku Support for a period of three hours, and neither of us could figure out how to get activerecord-jdbc-adapter to support SSL in a Rails 3.2 app (note Rails 3.2 does not support ENV(...) in database.yml).
My only recourse was this patch that made the library aware of environment vars.
Did I miss something?

These env vars aren't honored by the Postgres JDBC adapter, which is really a shame. So this patch actually brings the AR JDBC gem in-line with the native PG client, which does support the env vars.

these might have been in before but they still required some JVM option setting, that is likely the reason I commented out the first part ... sslmode = ENV['PGSSLMODE'] || ENV['PGREQUIRESSL'] if sslmode.nil?
is it working now just by setting these with the official driver?

also, AR-JDBC is (still) not compatible with latest 9.4 driver ... https://github.com/jruby/activerecord-jdbc-adapter/issues/710 (https://github.com/jruby/activerecord-jdbc-adapter/pull/746) be careful what you're using!

@kares I'm not exactly sure what you're asking, but before this patch, setting either PGSSLMODE or PGREQUIRESSL did not work. After this patch, they work.

OK - now I'm really not sure whether to merge this - we turn on SSL but than disable validation by default?

@kares i see what you're concerned about. The sslfactory=org.postgresql.ssl.NonValidatingFactory was necessary in pgjdbc versions earlier than 9.2. From 9.2 and onward, you can use sslmode=require, which attempts to validate the server certificate against the CA if it exists. But if it does not exist, it still uses ssl. This configuration is required on many cloud platforms, such as Heroku.

@kares also, given that the default when no properties are set is to not use SSL at all, using SSL with a NonValidatingFactory is still a step up.

part of AR-JDBC 1.3.22, thanks everyone!


[Dialog] with a long table and a tooltip shows additional scrolling bar

I have a dialog with a table in it that requires scrolling. The table contains a column that contains icons with tooltips. Everything is okay when tooltip placement='bottom'. When I change placement to 'right' an additional scrolling bar appears inside the dialog.

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Same as with Tooltip placement='bottom'
Steps to Reproduce (for bugs)

https://codesandbox.io/s/3v4wrk3jn1
Your Environment

Tech
Version

Material-UI
1.0.0-beta.21

React
16.0.0

browser
Chrome

I have encountered the same problem/a similar one:
To Reproduce
https://codesandbox.io/s/m7p9qlpjnp
As you can see in the example i posted, if the tooltip for example is at the edge of the Page which results in scrollbar, which shouldn't be there, if you move with the mouse over the button which creates the tooltip (and do this multiple times) then the tooltip starts to reposition itself into the correct position which would be the correct one.
I think the issue might be related to the window resize (i also encountered the same issue there), if resize the screen with the sandbox after it corrected itself, then i have the same issue again that it overflows and gradually corrects itself

Adding position: relative to root class in the DialogContent component fixes the scroll problem.
https://codesandbox.io/s/pyo6m17vz7?module=%2FHello.js


Able to add one line in bar chart, but can we add more than one line in a Bar chart.

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Version of the library being used [e.g. 1.2.17]

Additional context
Add any other context about the problem here.

Hi @DeepakAnthati 👋
Thanks for requesting this feature. From version 1.3.18 onwards, we support 2 lines in Bar charts. 🎉
To render the second line, we need to use the lineData2 prop.
The second line can be customised using the lineConfig2 prop.

Thank you @Abhinandan-Kushwaha !!


Support org without subscription and limit trial orgs

Fixes https://github.com/rilldata/rill-private-issues/issues/668

Organizations upon creation start with no subscription and never subscribed billing error
Trial is started either on first project deployment or manually using update subscription API
Upon sub cancellation, current sub will be valid until current billing cycle end and then no subscription. Quotas will be set to 0 and subscription cancelled billing error will be raised
Subscription can be renewed again using renew subscription API even before or after cancelled subscription ends. Cannot renew to a trial plan thus payment method and billable address should be present before renewing.

hmm...prettier check failing, not sure why


Invalid after iscustomelement configuration

Version
3.0.4
Steps to reproduce
app.config.isCustomElement = tag => tag.startsWith('x-')
This configuration alone has no effect, and then I did a certain vue.config.js It can be realized that there is no warning in templet, but if I use JSX syntax, it will still prompt that the component cannot be parsed. Is there a solution?
What is expected?
Normal pre resolution without warning
What is actually happening?
No pre resolution

Read and follow https://new-issue.vuejs.org/?repo=vuejs/vue-next#why-repro


Latest model adaptation code breaks regular training

I updated merlin this morning to the latest version. Trying to train a duration model from scratch, I get an error which is related to the latest model adaptation addition in run_merlin.py:
2017-09-19 09:35:13,022    DEBUG main.train_DNN: Starting train_DNN
2017-09-19 09:35:13,022    DEBUG main.train_DNN: Creating training   data provider
2017-09-19 09:35:13,023    DEBUG main.train_DNN: Creating validation data provider
2017-09-19 09:35:13,725     INFO main.train_DNN: building the model
2017-09-19 09:35:13,768     INFO main.train_DNN: load parameters from existing model: _
2017-09-19 09:35:13,768 CRITICAL           main: train_DNN threw an exception
I reverted back to the previous version of run_merlin.py for now. What should I put in the conf file to avoid this error? And is there an Interspeech paper or other instructions on what you can do with the model adaptation code if you wanted to?

Any idea how to fix the code for non-speaker adaptation training, or are you looking at that already?

I am also getting the same error
CRITICAL main: train_DNN threw an exception
Model file _ Does not exist
Is it so because its unable to find a model file?

Thank you for pointing out. It's fixed now.

Thanks I figured out the same and it has resolved the issue


fix(docs): update sidebar links

This updates the doc sidebar links so they all point a valid URL.
I noticed the deployed docs seem to be a bit behind and some sidebar links point to 404s.
Test Plan
esy '@doc' run and click all sidebar links

Thanks @paulshen ! Appreciate the fix :tada:


Speed up geometry functions

Speeds up geometry functions for calculating polygon intersection, especially for rectangles.

Nice 👍
Did you happen to profile the runtime of this solution? I'm wondering where we're spending the most time.

Yes, I used cProfile and found that the majority of the time was being spent on numpy array creation. I think at some point I might convert this to a numba program so it compiles jit.

Nice 👍
Did you happen to profile the runtime of this solution? I'm wondering where we're spending the most time.

Yes, I used cProfile and found that the majority of the time was being spent on numpy array creation. I think at some point I might convert this to a numba program so it compiles jit.

Fun! LMK if you start trying it out 🙂


Background event (onBackgroundEvent) is not triggered on click of action button when iOS app is killed

We have an app which require an action button to perform some activities in the background. We are using notifee along with react-native-firebase/messaging plugin.
When our iOS app is in the background and user clicks action button displayed using remote notification then onBackgroundEvent() function is trigged but when app is killed it's not being called. Below is my sample code written in index.js file.
notifee.onBackgroundEvent(async ({ type, detail }) => {
  const {notification}=detail;
  if (type === EventType.ACTION_PRESS && detail.pressAction.id === 'mark-as-read') {
    //Making API call here
  }

  await notifee.cancelNotification(notification.id)
})

Below is Payload being send from FCM
{
  “message”:{
    “token”:“”,
    “notification”: {
      “title”: “A notification title!“,
      “body”: “A notification body”,
    },
    “apns”: {
      “payload”: {
        “aps”: {
          “content-available”:1,
          “mutable-content”: 1,
        },
        “notifee_options”: {
          “image”: “https://placeimg.com/640/480/any”,
          “ios”: {
            “categoryId”: “mycategoryId”
          },
        },
      },
    },
  }
}

FYI- I have integrated the notification service extension to app, here is doc
Can someone help on this?, Thanks in advance

We are able to see logs when the device is plugged into the computer but when we killed the app from the recent tray in iOS debugging stop so unable to debug.
onBackgroundEvent gets fired when the app is in the background state and onForegroundEvent in the foreground state.
But the issue is with the killed state. The action button won't work after the app is killed to validate we added one API call on the action button press which will send a mail to us. Work fine in background but not working in killed state

Console.app allows you to see logs independent of debugging state, on a plugged in device, I think

Hi Mike,
Thanks for the quick response.
The issue was with Xcode I guess when we connect the physical device and run the build it was creating the problem, but when we tried to generate a .ipa file and run it on the device its worked fine we were able to receive background event.

I am always happy to hear it when things work, but that is odd that the debuggable (and with debugger running) version did not work. I wonder what would happen if you built it on the device from the command line, then watched the logs from Console.app :thinking: - that would mean you're still using a debug / debuggable build, just that no debugger was currently attached. It is only interesting because from a support perspective, if using a debugger means this doesn't work, that's really worth documenting. If however it is a difference between debug and some other way of building it (did you use TestFight?) then maybe there is a timing bug


added support for traits

This lack of feature is the only thing stopping us from adopting Fixie. We use TFS (unfortunately) and there are two issues:

all tests will run on the TFS CI Server no matter what traits I specify
there is no way to run only a specific category of tests in Test Explorer

@plioi  Can this be closed now?  It's old and I wonder if relevant to the new version?

@StevenTCramer Yeah, unfortunately the .NET Core kerfuffles have put our priorities upside down for a long time, and the design has moved significantly in the meantime as a result. Closing this PR, but I've opened #208 to cover the tentative desire for the feature.


Arrow on end/left for right-to-left locale

How do we show arrow on left for rtl languages like arabic?

Please use ms_isRtl


Method of checking md5sum

Something really minor, but is there a reason why the installation tutorial says to check md5sum using the below?
md5sum Demuxafy.sif > downloaded_Demuxafy.sif.md5
diff -s Demuxafy.sif.md5 downloaded_Demuxafy.sif.md5

I think using the below is more general...?
md5sum -c Demuxafy.sif.md5

Really no good reason except that I didn't know about the method you suggested. I just tested your suggestion on the md5 file I generated and it worked well. I'll update the docs when I have time to reflect this easier method of validation.
Thanks for the input! I'll leave this open until I make the changes and commit them

@drneavin Great to hear it was helpful! Just started reading your paper, and it's really impressive how you've used so many methods and integrated them all into one framework. Looking forward to understanding your approach further as I read the paper.


[core,arm] Various fixes and adjustements for #9363

Treat the case where the publicIpAddress is there but empty.
Don't try RDSTLS if the password has not been been provided.
When RDSTLS is what we will do, disengage all the other security kinds.

@freerdp-bot test
@hardening is this ready now?

PR has been updated and is ready


Add logging for os-wireguard

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
[x] When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
When trying to debug Wireguard connections it is incredibly frustrating to do so.
Describe the solution you'd like
I would love a panel / tab for the Wireguard plugin that lets me see things like "Attempted connection" or whatever to be able to somehow trace where the issue could be.
Describe alternatives you've considered
None, because this is specific to Wireguard.

Wireguard itself doesnt log anything

Would it be possible to build custom logging/debugging for this (e.g. checking connections, displaying error states)? Is there a good alternative that is better debuggable?

OpenVPN works best

Thanks for the tip! Will try ;)

Closed accidentally.


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
https://www.youtube.com/watch?v=RSncufswJ-I&lc=UgykEO1YpTl5Cra_v_h4AaABAg.9dJl4qyIH299dJlLLrTXbI
(Optional) Screenshot of comments referencing the scam account

(Required) List of the scam account names
callucas

Added