[#963]tars return value polish.

// Describe your PR here; eg. Fixes #issueNo

Make sure that:

[ ] You have read the contribution guidelines.
[ ] You submit test cases (unit or integration tests) that back your changes.
[ ] Your local test passed mvn clean install -Dmaven.javadoc.skip=true.

Codecov Report

Merging #964 (1fb9a26) into master (a96cee7) will decrease coverage by 0.89%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #964      +/-   ##
============================================
- Coverage     77.37%   76.47%   -0.90%
+ Complexity     2045     1971      -74
============================================
  Files           331      324       -7
  Lines          7505     7299     -206
  Branches        832      806      -26
============================================
- Hits           5807     5582     -225
- Misses         1250     1301      +51
+ Partials        448      416      -32

Impacted Files
Coverage Δ
Complexity Δ

...soul/client/tars/TarsServiceBeanPostProcessor.java
19.17% <0.00%> (-26.66%)
5.00 <0.00> (-5.00)

...soul/client/sofa/SofaServiceBeanPostProcessor.java
20.96% <0.00%> (-43.55%)
5.00% <0.00%> (-3.00%)

.../metrics/facade/handler/MetricsTrackerHandler.java
91.07% <0.00%> (-3.58%)
23.00% <0.00%> (-1.00%)

.../soul/plugin/httpclient/NettyHttpClientPlugin.java
57.14% <0.00%> (-2.05%)
10.00% <0.00%> (ø%)

...omara/soul/sync/data/http/HttpSyncDataService.java
72.54% <0.00%> (ø)
12.00% <0.00%> (ø%)

...elimiter/handler/RateLimiterPluginDataHandler.java
74.13% <0.00%> (ø)
12.00% <0.00%> (ø%)

...oul/plugin/tars/handler/TarsPluginDataHandler.java

.../soul/plugin/tars/response/TarsResponsePlugin.java

...plugin/tars/subscriber/TarsMetaDataSubscriber.java

... and 2 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #964 (1fb9a26) into master (a96cee7) will decrease coverage by 0.89%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #964      +/-   ##
============================================
- Coverage     77.37%   76.47%   -0.90%
+ Complexity     2045     1971      -74
============================================
  Files           331      324       -7
  Lines          7505     7299     -206
  Branches        832      806      -26
============================================
- Hits           5807     5582     -225
- Misses         1250     1301      +51
+ Partials        448      416      -32

Impacted Files
Coverage Δ
Complexity Δ

...soul/client/tars/TarsServiceBeanPostProcessor.java
19.17% <0.00%> (-26.66%)
5.00 <0.00> (-5.00)

...soul/client/sofa/SofaServiceBeanPostProcessor.java
20.96% <0.00%> (-43.55%)
5.00% <0.00%> (-3.00%)

.../metrics/facade/handler/MetricsTrackerHandler.java
91.07% <0.00%> (-3.58%)
23.00% <0.00%> (-1.00%)

.../soul/plugin/httpclient/NettyHttpClientPlugin.java
57.14% <0.00%> (-2.05%)
10.00% <0.00%> (ø%)

...omara/soul/sync/data/http/HttpSyncDataService.java
72.54% <0.00%> (ø)
12.00% <0.00%> (ø%)

...elimiter/handler/RateLimiterPluginDataHandler.java
74.13% <0.00%> (ø)
12.00% <0.00%> (ø%)

...oul/plugin/tars/handler/TarsPluginDataHandler.java

.../soul/plugin/tars/response/TarsResponsePlugin.java

...plugin/tars/subscriber/TarsMetaDataSubscriber.java

... and 2 more

Continue to review full report at Codecov.

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


Recommender.py for FastAPI

Describe your changes
Created the .py file for the recommender that FastAPI will reference to.
Issue number
#99
Closes #99
Checklist before requesting a review

[x] Performed a self-review of my code
[x] Formatted my code with pkgmt format

:books: Documentation preview :books:: https://ploomber-sql--100.org.readthedocs.build/en/100/

Hi @lfunderburk
Can you take a look at what I have so far? My main concern regards my comment on how we would connect to the S3 Bucket using Lambda.
Besides that, I think the main get_recommendation function is of viable use for FastAPI.

Please navigate to the /recommendations folder and run uvicorn app:app --reload to launch the API.
Go to http://<IP_ADDRESS>:8000/docs#/default in your browser to test out the API with a movie. I used the movie "Barbie" and received the expected output.

Hi @jpjon
Did a bit of code clean up, type checking, pydantic modelling and added some testing
To execute tests
cd sql/mini-projects/movie-rec-system
pytest

From the Docker container we don't want to specify the path, we should be running things from the root directory (in this case sql/mini-projects/movie-rec-system)
Please execute the app as follows
 uvicorn movie_rec_system.app.app:app --reload

Changed made to fix warnings:
Replaced @validator with @field_validator: https://events.bizzabo.com/458007/settings/registration/1eaNwY9AETInoqcCd_pBC3mdpyVozaTeGSNDrqw3yMsJPmiZu8MIS4Fbc0Qmsa1f
Added additional test for validating response:
https://events.bizzabo.com/458007/settings/registration/1eaNwY9AETInoqcCd_pBC3mdpyVozaTeGSNDrqw3yMsJPmiZu8MIS4Fbc0Qmsa1f


Unknown Stopped

Hi,
Im currently getting the "Unknown Stopped" error intermittently on this module. Any idea what might be causing it? Or any advice to try?
Trying to get logs from the modules itself (have 3 instances running) but keep missing it.
Im on 3.0.1 (3.0.1+6068-stable-a05a9c89)
Companion log attached.
GIG17E_companion_log_20230918-1637.csv.zip

This error suggests that the projector is off (hard switch, not standby):
Network connect EHOSTUNREACH <IP_ADDRESS>:4352
Have you tried the beta (3.1) Companion release?

Hi John, thanks for the quick reply.
Projectors have power (switching the module on and off resolves the issue)
As its intermittent and seems to be happening on multiple machines it might be a network or hardware issue :/
Projectors are Epson EB-L630SU
Havent tried the beta, will give it a shot.

I also have a Epson projector And am experiencing the same issue.
I have 3 instances going too! The other 2 are NEC projectors are working properly.
The epson however, will only work if you restart the whole companion application. And it will only work for less than 24 hours.

@ldhall1856 Companion 3.0 was a big rewrite. There have been issues cleared up in the beta (3.1) release. Some of the 'errors' and 'warnings'  shown in companion do not affect how the module works.

Which modules are you having trouble with?

Home assistant

Darn. Not one of mine.


Microsoft.Dynamics.Nav.Model.IO.Txt.TxtImportException: Begin expected.

For some reason this text export has a ; where the begin should be.

BeginExpected.zip

Here's your problem:

I come across this during merges as well - the model.tools have problems with this as well.

Thanks. ;-)


Disable Auto-fil once and for all

https://bitsharestalk.org/index.php?topic=13546.msg176836
Auto-fill is useless in general .

autofill was only ever supposed to be for favorited accounts anyway

fixed


Initial pass at an init command

As discussed in #144 an init command might be nice.
This is probably the first time I have ever written any Rust so I just tried copying things I saw in the existing implementation and did some work arounds to compile errors using ChatGPT.
Ideally someone with some experience could help turn this into a proper solution that is more idiomatic etc!
I added the config file creation at a point before the configuration load happens to avoid it blowing up but Im sure there is a better solution here.
Anyway thought it might be a starting point!

Will do!

@alexevanczuk apologies for the delay on this, I will pick it up again asap

No rush @stevegeek ! Totally on your schedule here :)

@alexevanczuk made some changes to the way I had implemented this command. Think this implementation solves a few of the issues with the previous one. Added a test too

Looks good, one thought that we should just create one YML file to start. I kind of like the idea of just creating the packs.yml and referencing pks commands instead of packwerk commands, since if someone is starting a new app for the first time it's a good time to start using pks from the beginning, what do you think?

Makes sense to assume one would be using pks from the get go in this case. I will look at packs first mode, didnt even notice it before, have always used a packwerk.yml

Also you have a couple of lint errors but if you run cargo fmt && cargo clippy it should show you where they are! There are some cmd line flags to auto fix too (you can have this set up in your editor to auto-fix lint errors).

Ok, yeah I saw there was a githook but it was blowing up and I couldn't work out how to get it to run so committed without it. will make sure to run the formatter next time!

Nice!! Just two very small changes requested:

Can ya add that inline comment about why the case on the command is higher for init?
Want to bump the patch version in Cargo.toml? That will allow the new version to be auto-published when merged 🎉


elisp_manual() needs to accept additional inputs

As an example, magit/ghub's doc is an .org file which tries to pull in an org setup file: https://github.com/magit/ghub/blob/main/docs/ghub.org?plain=1#L12
There's no way right now to pass that setup file (.orgconfig) to elisp_manual to generate the texinfo.

OK, I guess we want something like additional_inputs, similar to additional_compiler_inputs for cc_library etc.

The latest commit (9b31929) works and generates the texi docs correctly.  Thanks!


Datacite - enhance metadata

Fixes #952

Currently, datacite branch has more updates regading DOIs and is not ready to be merged


want to fix the space between different section.

want to change margin between different sections. that will make the website look good and spacious.

please assign me this issue @codervivek5 under GSSOC'23.

kindly add issue number at PR time

ok sir. Sir what's the deadline for this.


Support --username option for Chaturbate

Checklist

[x] I'm reporting a site feature request
[x] I've verified that I'm running youtube-dl version 2020.01.01
[x] I've searched the bugtracker for similar site feature requests including closed ones

Description
It would be nice if youtube-dl supported the --username option for Chaturbate, to download a stream that is only available to certain users (e.g. users who have purchased a ticket for a hidden show).

You must provide account credentials.

@dstftw: I am saying providing account credentials does not work. Even if I have a ticket for a hidden show, youtube-dl --username <my-username> --password <my-password> <url> will say "Room is currently offline".

As far as I can tell, there is no code in chaturbate.py that checks for the --username and --password options and forwards them to the server in any way.

Again: you must provide account credentials to developer.

Oh, I see.
Do they need to be credentials for an account that has purchased tokens? Is there a way to provide them privately?

It must be an account with access to whatever you request.

In case an account has yet to be provided here is a dummy account:
user: dummy010203
password: Password010203
Since this issue happens with any stream I figured this account should do the trick

has this been resolved?
I'm trying to download from chaturbate using  the username & password flags, but it doesnt seem to be working.
should i open a new ticket?

has this been resolved?

I don't think so.
One challenge is you generally need to spend tokens to even test this kind of scenario.


chore(autoload): allow to autoload specific folders in dev mode

Download Artifacts :

win-ia32
win-x64
linux-x64


check for shadowing of predeclared identifiers

Go defines 39 predeclared identifiers. These identifiers can be shadowed in user-written Go code.
Types:
	bool byte complex64 complex128 error float32 float64
	int int8 int16 int32 int64 rune string
	uint uint8 uint16 uint32 uint64 uintptr

Constants:
	true false iota

Zero value:
	nil

Functions:
	append cap close complex copy delete imag len
	make new panic print println real recover

Example
Consider a file:
package main

type T struct {
	x, y int
	s string
}

func main() {
	a := []T{{x: 0}, {x: 1}, {x: 2}}
        print(a[1])
	b := make([]T, 3)
	copy(b, a)
}

And another file in the same package with these definitions:
package main

// order of src and dst is switched from the builtin copy!
func copy(src, dst []T) {
	for i := range dst {
		if i == len(src) {
			break
		}
		string := src[i].s
		dst[i].s = string
	}
}

// not the builtin print as expected!
func print(t T) { log.Printf("{ x=%d, y=%d }", t.x, t.y) }

Most Go programmers would expect that the copy and print used in the first file are the builtin copy and print functions. Shadowing them adds confusion and cognitive overhead. So check for declarations that shadow the predeclared identifiers.
See #416.

We will add predeclared as one of the first candidates for integration via #380.


Iris validation

I have added a new node package to dev dependencies called iris-validation-backend. This package is essentially just the web assembly and js bindings for the iris metric calculations.
I have added a call to this module in the MoorhenIrisValidation file.
The iris-validation-backend module contains two functions :

calculate_single_pdb(pdb_filename: string, density_filename: string, reflections: boolean)
calculate_multi_pdb(pdb_filename1: string, pdb_filename2: string, density_filename: string, reflections: boolean)

where reflections=true when working with an MTZ and false with a MAP.
Example usage:
let backend_call;
  if (filenames.length == 2) {
      backend_call = Module.calculate_multi_pdb(...filenames, mtz_path, true)
  }
  else {
      backend_call = Module.calculate_single_pdb(filenames[0], mtz_path, true)

  }
  setResults(backend_call.results)

Currently, this code breaks when no molecules are loaded and the drop-down for molecule selection does not work. I imagine there should be a drop-down for which molecule(s) to use and what map to use. There could also be a drop-down for what chain to look at. There are no props for selecting molecule or chain since it normally comes from within Iris but I will add that soon.
Also added are the callback functions for a click event and hover event.

Thanks for this, I just have a question about emscripten bindings but otherwise I think I'll just merge and take care of the other changes myself.


fix: add prefix to enum type definition

Seems enum type has the user-specified prefix as class property, while has no prefix as definition.
Tested query (GitHub API v4):
{
  node(id: "") {
    ... on Commit {
      status {
        state
      }
    }
  }
}

The state in this query is an enum.

Thanks @pd4d10!
I'm fixing the actions pipeline to see if all tests pass (it shouldn't, or we need more tests 😂)

Now we do have tests!


Unexpected side-effect of sampling profiler with file copy within transaction

When the following conditions are met, there are unexpected side-effects on file copy operations

Java agent attached with -javaagent
Sampling profiler enabled elastic.apm.profiling_inferred_spans_enabled=true
within an active transaction elastic.apm.trace_methods=Main#transactionMethod
trying to copy a rather large file, above ~50 mb with using FileChannel (could also happen with other APIs, but I haven't tested yet).

The issue was initially reported when deploying a .war on tomcat through the manager webapp (by providing the path to the .war to deploy, not using upload), but in fact the is not Tomcat specific.
One of the likely reasons this was not detected reported earlier is because large file copy operations are rarely triggered from a transaction, and that the used API might not be the most commonly used.
The following code allows to reproduce the issue by creating a 100mb file and trying to copy it, when the sampling profiler is enabled the file copy is less than expected (about ~51mb, but the actual value and threshold to trigger might be OS-dependant).
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.channels.FileChannel;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.nio.file.StandardOpenOption;

public class Main {

    public static void main(String[] args) {

        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            // ignored
        }

        // needs to be within a transaction
        transactionMethod();
    }

    private static void transactionMethod() throws IllegalStateException, RuntimeException {

        Path tmp = Paths.get(System.getProperty("java.io.tmpdir"));
        Path source = tmp.resolve("source");
        Path destination = tmp.resolve("destination");

        try {
            Files.deleteIfExists(source);
            Files.deleteIfExists(destination);

            // generate a ~100mb source file
            byte[] data = new byte[100*1024*1024]; // 100mb of zeroes
            Files.write(source, data, StandardOpenOption.CREATE, StandardOpenOption.APPEND);

            // those few lines emulates the way tomcat copies the .war file before deployment
            // in org.apache.catalina.startup.ExpandWar.copy
            try (FileChannel ic = (new FileInputStream(source.toFile())).getChannel();
                 FileChannel oc = (new FileOutputStream(destination.toFile())).getChannel()) {
                ic.transferTo(0, ic.size(), oc);
            }

            if (Files.size(source) != Files.size(destination)) {
                // will be thrown for large files when within a transaction + sampling profiler enabled
                throw new IllegalStateException("file size do not match !!");
            }

        } catch (IOException e) {
            throw new RuntimeException(e);
        }

        System.out.println("that's fine !");
    }
}

Does the issue also happen with async-profiler 2.x?

doesn't reproduce on Ubuntu 22.04.2, does on RHEL 9.0

Does the issue also happen with async-profiler 2.x?

I did a basic swap-in replacement (so the profile data failed to get populated, but the profiler did run), and the failure is the same

Note that although on RHEL the failure is reproducible, it occasionally doesn't happen and the file copy completes

Finally made progress by going down to the native calls and back up ... only to find it's a tomcat bug which Sylvain perfectly reproduced. I've opened a tomcat PR with a proposed fix.
Basically, tomcat calls FileChannel.transferTo() just once, assuming it will complete the file transfer, but here it only does a partial transfer, so it needs to loop to complete the transfer. The reason this is seen here and not in most tomcat deployments is that async-profiler installs signal handlers for signals, and the CPU time slicer signals (it could really be any signal, but I'm seeing the CPU time slicing in my tests) which interrupts the file copy transfer so that only part of it gets transferred. I guess most WARs are small enough and the OS call efficient enough that you need a particular combination to get the transfer interrupted like this (it looks like it needs the profiler to be active at the time of the transfer, but I couldn't be certain because of the overhead strace imposes which meant it was really hard to reproduce the bug with strace running).
Workaround alternatives:

turn off the profiler
reduce the frequency of the profiler
patch the tomcat installation with the one file change per the PR


not enough master nodes discovered during pinging - Elasticsearch cluster self signed certificate

I used SearchGuard to encrypt nodes in ElasticSearch cluster following this guide: https://gryzli.info/2018/12/01/elasticsearchelk-stack-security-howto/
Master:
cluster.name: client1
searchguard.enterprise_modules_enabled: false

node.name: ekl.test.com
node.master: true
node.data: true
node.ingest: true

network.host: <IP_ADDRESS>

#http.host: <IP_ADDRESS>
network.publish_host: ["ekl1.test1.com","ekl.test.com"]

http.port: 9200

discovery.zen.ping.unicast.hosts: ["ekl.test.com", "ekl1.test1.com"]

discovery.zen.minimum_master_nodes: 1

xpack.security.enabled: false

searchguard.ssl.transport.pemcert_filepath: '/etc/elasticsearch/ssl/node1.pem'
searchguard.ssl.transport.pemkey_filepath: 'ssl/node1.key'
searchguard.ssl.transport.pemtrustedcas_filepath: '/etc/elasticsearch/ssl/root-ca.pem'
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.transport.resolve_hostname: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.pemcert_filepath: '/etc/elasticsearch/ssl/node1_http.pem'
searchguard.ssl.http.pemkey_filepath: '/etc/elasticsearch/ssl/node1_http.key'
searchguard.ssl.http.pemtrustedcas_filepath: '/etc/elasticsearch/ssl/root-ca.pem'
searchguard.nodes_dn:
- CN=ekl.test.com,OU=Ops,O=BugBear BG\, Ltd.,DC=BugBear,DC=com
- CN=ekl1,test1.com,OU=Ops,O=BugBear BG\, Ltd.,DC=BugBear,DC=com
searchguard.authcz.admin_dn:
- CN=admin.test.com,OU=Ops,O=BugBear Com\, Inc.,DC=example,DC=com

Node:
cluster.name: client1
searchguard.enterprise_modules_enabled: false

node.name: ekl1.test.com
node.master: false
node.data: true
node.ingest: false

network.host: <IP_ADDRESS>

#http.host: <IP_ADDRESS>
network.publish_host: ["ekl1.test1.com","ekl.test.com"]

http.port: 9200

discovery.zen.ping.unicast.hosts: ["ekl.test.com", "ekl1.test1.com"]

discovery.zen.minimum_master_nodes: 1

xpack.security.enabled: false

searchguard.ssl.transport.pemcert_filepath: '/etc/elasticsearch/ssl/node2.pem'
searchguard.ssl.transport.pemkey_filepath: 'ssl/node2.key'
searchguard.ssl.transport.pemtrustedcas_filepath: '/etc/elasticsearch/ssl/root-ca.pem'
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.transport.resolve_hostname: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.pemcert_filepath: '/etc/elasticsearch/ssl/node2_http.pem'
searchguard.ssl.http.pemkey_filepath: '/etc/elasticsearch/ssl/node2_http.key'
searchguard.ssl.http.pemtrustedcas_filepath: '/etc/elasticsearch/ssl/root-ca.pem'
searchguard.nodes_dn:
- CN=ekl.test.com,OU=Ops,O=BugBear BG\, Ltd.,DC=BugBear,DC=com
- CN=ekl1.test1.com,OU=Ops,O=BugBear BG\, Ltd.,DC=BugBear,DC=com
searchguard.authcz.admin_dn:
- CN=admin.test.com,OU=Ops,O=BugBear Com\, Inc.,DC=example,DC=com

Certificates are self-signed
From node i can telnet to ports 9200/9300 by hostnames
curl -kvX GET “https://admin:pass@ekl.test.com:9200” works fine (need to use -k to avoid cert verification because it’s self-signed)
Errors on node:
[ekl1.test1.com] not enough master nodes discovered during pinging (found , but needed 1), pinging again
Both server names are correct
I suspect issue is in self-signed certificate
If i specify IP instead of hostnames then getting:
Illegal parameter in http or transport request found. This means that one node is trying to connect to another with a non-node certificate (no OID or searchguard.nodes_dn incorrect configured) or that someone is spoofing requests.
ES Config path is /etc/elasticsearch [2019-03-28T21:25:56,450][INFO ][c.f.s.s.DefaultSearchGuardKeyStore] >[ekl1.test1.com] OpenSSL not available (this is not an error, we simply >fallback to built-in JDK SSL) because of java.lang.ClassNotFoundException: >io.netty.internal.tcnative.SSL

Found it: had to add to non-master:
transport.tcp.port: 9300
discovery.zen.ping.unicast.hosts: ["ekl.test.com:9300"]
transport.host: ekl1.test1.com


Detect if an element has been clicked

Describe the solution you'd like
When the user clicks on the canvas a function runs to detect if a drawn element was close enough to that click to consider it a hit
if it's indeed a hit select that element

[ x]  Rectangle
[ x]  Line


Branch mixin does not update this.cursors and this.facets in componentWillReceiveProps

This causes problems with components using cursor paths with properties in them when they attempt to change the data via this.cursors.
cursors: function(props) {
    return {data: ['views', 'users', props.user.id, 'balance']};
},

Elsewhere:
this.cursors.data.set(data);

Once properties have changed this.cursors will point at the wrong set of cursors.
The fix in mixins.js is simple:
componentWillReceiveProps: function componentWillReceiveProps(props) {
    if (!this.__facet) return;
    this.__facet.refresh([props, this.context]);

    this.cursors = this.__facet.cursors;
    this.facets = this.__facet.facets;

    this.setState(this.__facet.get());
}

I can send a PR if you like but its only 2 lines of code to add.

Hello @davidtinker. You are right indeed. I forgot this. Would it be possible for you to sketch a PR fixing the issue for mixins and higher-order components etc. also please?

This should be fixed with the latest version of the library. Do you need a retro-compatible fix?


querying one entity that has read only permission won't give any result

Using
		query product($id: String!) {
			product(id: $id) {
				id
			}
		}

On an entity that has read only permission won't give any result back.

If you query all products, do you see the one with that id?

If you query all products, do you see the one with that id?

Not sure what you mean.
If I add the class level permission of Query, I do receive a result. If I don't add the class level permission, by definition I cannot query all products.

 What is the result of a products query (which should return all objects) - do you get an object with id: 123 or is it missing altogether? I'm just trying to narrow down the potential issue. Also, if you use a native SDK (e.g. node/swift/etc.), do you get the object - i.e. is this an issue that only affects GraphQL or all clients trying to connect to that partial realm?

 What is the result of a products query (which should return all objects)

Unless I'm mistaking, if a class has permissions:
    canRead: true,
    canQuery: false,

Your statement  "which should return all objects" is false.
But If I set the permissions to
    canRead: true,
    canQuery: true,

Then I do receive the object.

Also, if you use a native SDK (e.g. node/swift/etc.), do you get the object - i.e. is this an issue that only affects GraphQL or all clients trying to connect to that partial realm?

I assume the answer is yes and that it's a problem with gql only. But I didn't try and I'm kind of in a hurry so I cannot do it right now. Maybe tomorrow

Just to be more clear, as I see this is still pending.
I think the issue arose when
    canRead: true,
    canQuery: false,

won't give any result for
		query product($id: String!) {
			product(id: $id) {
				id
			}
		}


Is it possible to obtain the image domain embedding converted from learned * ?

Hello @rinongal , thanks for the great work! Just finished my concept training and the result looks good for me.
(Edited)
To my understanding, the stable diffusion uses CLIP convert the text prompt to image domain embedding to inject the information into model and ldm uses BERT. If we are using "A photo of *" as prompt, and I want to get the embedding. I just need to send the prompt to BertEmbedder (in /ldm/modules/encoders/module.py) for converting to text embedding, right?
If so, will the text embedding be used as a conditional input and be cross-attended by model? Or will it be further projected to image domain like what CLIP do?
Another quick question, is the BertTokenizer used in your work?

(Reply by myself)
Actually we can get the converted embedding from desired pretrained checkpoint.
First, loaded the model as what described in the beginning of txt2img.py.
Then, run
model.get_learned_conditioning("prompt")
It will return the embedding that will be used in inference as condition.


Get rid of '..' path in templates

The path '..' is special to UNIX.
When running under non-UNIX-like file systems,
@extends "../common.snip"
does not work since the directory ".." loses its special meaning.
"Non-UNIX-like file systems" may also appear on UNIX systems.
If the project is packaged into a JAR for distribution,
the '..' directory will still fail, since a JAR is a Zip archive,
and a Zip archive does not have '..' directories.
The '..' was used in the first place to reuse template code stored in
"codegen/common.snip", while the resource root is in subdirectories,
like "codegen/go".
This commit changes the resource root of all template renderings to
"codegen".
In this way, "codegen/common.snip" can simply be used by
@extends "common.snip"
and files in subdirectories can be used by
@extends "subdir/foo.snip".
Fixes #260.

@garrettjonesgoogle PTAL

Friendly ping @garrettjonesgoogle @vchudnov-g

afaict, lgtm, but see what @garrettjonesgoogle has to say.

In my PR https://github.com/googleapis/toolkit/pull/268 , the treatment of snippet set runners is diverging; in the refactored model, there is only a single snippet set runner class, CommonSnippetSetRunner. I'm thinking that maybe we should wait on the changes for '..' and apply them to the refactored world.

Hmm, this change seems relatively small enough that I would favor submitting it now, locking it down with tests, and then ensuring that in the refactored world makes the tests pass. (I assume the idea is that the baseline tests would carry over into the refactored world.)

I looked over it again and there shouldn't be any conflicts. LGTM.

OK, I'll merge this. Of course, feel free to back this out if it causes problems :smile:


Improve Core response when a connector is unavailable/down/etc.

JIRA issue created by: rcook
Originally opened: 2013-01-10 11:22 AM
See issue NCIP-144.

JIRA User: bodfishj
JIRA Timestamp: 2013-03-19 11:15 AM
It isn't literally true that the core knows that a connector is unavailable/down/etc. I think the way this manifests in the core is an uncaught exception. I expect I have to wrap the calls into the connector so as to catch any exception they throw, log it and return an NCIP Problem response. The logging and returning of the NCIP Problem response is already there for other exceptions, so this should be a simple matter of adding a catch block for any exception type.


refactor: rename test util

It was a misnomer, we're asserting the queue, not the entire pool.

Stack:

#429
#428
#427
#426 ⬅

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

This change is

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 83.54%. Comparing base (09efafe) to head (2af4855).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #426   +/-   ##
=======================================
  Coverage   83.54%   83.54%
=======================================
  Files          37       37
  Lines        1720     1720
  Branches     1720     1720
=======================================
  Hits         1437     1437
  Misses        206      206
  Partials       77       77

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[bug]: Invalid small transaction causing on-chain funds to be stuck in Pending state

Background
I am currently running a Lightning Network node using the Voltage service. Due to an invalid transaction of 147 sats, most of my on-chain funds are stuck in Pending state.
A brief history of the issue:

In the past, the channel opening transaction fee was set too low, resulting in the channel not opening properly. I then force-closed the channel.

I reported this issue previously: [bug]: Channel Issue After Resolving Pending Opening Transaction with CPFP (edge not found)

The funds tied to the force-closed channel returned to my on-chain wallet.

closing_tx_hash: 72886b507bc08da367b2b4a9690654b99e97420a596677e378fc449d69ef8707

I thought everything was going smoothly until an invalid transaction of 147 sats propagated and caused the on-chain funds to be stuck in Pending state.

To my knowledge, this transaction started to occur after upgrading the node to version 0.16.x.
The invalid transaction's txid is e7ace4fae0e4b732135d358a638aea1f738d8bd86d5fec07068a6d40dc4606b6, but it cannot be verified in the mempool as it is invalid.
The reason for considering the transaction invalid is that the output address is different from the one where I received the funds after closing the channel.

147 sats output address: bc1plwgx7mmttulrnud6ne0efvl5st22ey3p33kxvpvgqf3lj40fnu0qc3gwa6
Address where I received the funds after closing the channel: bc1ptfrkmhksynem3fmp74e9mp0vwv7ezkz6c4nv0d6duhyjx3x48wrsmm35gk

With the help of a Voltage engineer, I performed wallet rescans three times, but the issue persists.

it seems that the problematic transaction was propagated during the rescan.

Your environment

version of lnd: 0.16.2-beta (exact version unknown)
operating system: N/A (hosted by Voltage)
backend: unknown (managed by Voltage)
any other relevant environment details: N/A

Steps to reproduce

Run a Lightning Network node using the Voltage service.
Upgrade the node to version 0.16.x.
Encounter an invalid transaction of 147 sats that causes on-chain funds to be stuck in Pending state.

txid: e7ace4fae0e4b732135d358a638aea1f738d8bd86d5fec07068a6d40dc4606b6

Perform wallet rescans with the help of a Voltage engineer, but the issue persists.

Expected behaviour
The invalid transaction of 147 sats should not affect the on-chain funds, and they should not be stuck in Pending state.
Actual behaviour
The invalid transaction of 147 sats is causing the majority of my on-chain funds to be stuck in Pending state, and the issue persists even after performing wallet rescans.

Hi @sogoagain, I have a couple of questions:

What are the inputs/outputs for that 147 sat tx?
How does it relate to your other funds. For example the ones in this address?

@Roasbeef, Thank you for checking into the issue. I've looked into issue #4760, but it seems to be different from the problem I'm experiencing. The problematic transaction in my case does not appear to be related to opening a channel.

Hello, @positiveblue :)
Thank you for looking into the issue and for your questions. I'll provide answers to your questions below.

What are the inputs/outputs for that 147 sat tx?

To check the details of the transaction, I ran the lncli wallet listsweeps --verbose command and found the following information (I didn't see the input value, is there any way to check it?) :

{
  "tx_hash": "e7ace4fae0e4b732135d358a638aea1f738d8bd86d5fec07068a6d40dc4606b6",
  "amount": 147,
  "time_stamp":<PHONE_NUMBER>,
  "dest_addresses": [
    "bc1plwgx7mmttulrnud6ne0efvl5st22ey3p33kxvpvgqf3lj40fnu0qc3gwa6"
  ],
  "output_details": [
    {
      "output_type": 9,
      "address": "bc1plwgx7mmttulrnud6ne0efvl5st22ey3p33kxvpvgqf3lj40fnu0qc3gwa6",
      "pk_script": "...",
      "amount": 993404,
      "is_our_address": true
    }
  ],
  "raw_tx_hex": "...",
  "label": "0:sweep",
  "previous_outpoints": [
    {
      "outpoint": "72886b507bc08da367b2b4a9690654b99e97420a596677e378fc449d69ef8707:0"
    },
    {
      "outpoint": "6817fe7ce18d00b2451cd9ea8ce1d21ff27b49aecaaa1939281d87c4d59d8812:0",
      "is_our_output": true
    }
  ]
}

How does it relate to your other funds. For example the ones in this address?

The address bc1ptfrkmhksynem3fmp74e9mp0vwv7ezkz6c4nv0d6duhyjx3x48wrsmm35gk is where the funds were deposited after closing the Lightning channel. Based on the information related to your first question, it seems that the problematic transaction is attempting to send 147 sats to that address. Is that correct?

Thank you.

This sweep tries to co-spend from a force close transaction's outputs anchor_to_local and to_local, where the anchor was already swept by https://mempool.space/tx/60a74dd825094a29a5db68cd4e1dcbf7f031d300c9a7b8d1c954908aaef62be7#vin=4.

Hello, I think I may have similar issue

Got random force-closed channel recently with this closing tx : 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691
Right after the tx was broadcasted, another one came up as lightning anchor: 8228d8f4010208d974e696cea1fc86475ca19cb48243cc831953ea6065544ca2
And then got replaced by ba06001ad42dddf5e18855a97eca1cc4a8685d40e341b3c20c5384dc434f337e as "swept lightning anchor".
The following input which was used for the 330sat anchor tx is now showing as unconfirmed in LND 8228d8f4010208d974e696cea1fc86475ca19cb48243cc831953ea6065544ca2#vin=1 and is no longer valid in mempool.

lncli listunspent
         "address_type": 4,
         "address": "bc1pfn3zyrk5hmp5ctze74td02c0tfj33mefg8v2hukjm4arq6gpanhqywa6uy",
         "amount_sat": 2170217,
         "pk_script": "51204ce2220ed4bec34c2c59f556d7ab0f5a6518ef2941d8abf2d2dd7a306901ecee",
         "outpoint": "8228d8f4010208d974e696cea1fc86475ca19cb48243cc831953ea6065544ca2:0",
         "confirmations": 0

Anything I can do about it ? The swept anchors fee is so low that I doubt it will get ever confirmed in the current state of mempool.
lnd 0.16.2
Thank you.

Hi @bitromortac,
Thanks for your time and attention on this matter.
Considering your feedback, what could be the best solution to my problem? I noted that the milestone for PR #7599, which you've indicated has resolved the issue, appears to be set for 'v0.16.1'. If memory serves, the bug I'm facing started to show up after I updated my node to version 0.16.x.
Is it possible that this problem is an unintended consequence of that PR? I'm eager to find out if there's any way to rectify this. I appreciate your help.

@bitromortac, Well I am mainly concerned about the unconfirmed input I have sitting in LND as mentioned above.
I am not sure what exactly to look for, this is the latest log for the first sweep which is no longer in mempool.
sudo journalctl -u lnd | grep 8228d8f4010208d974e696cea1fc86475ca19cb48243cc831953ea6065544ca2
2023-05-10 15:18:31.504 [INF] SWPR: Creating sweep transaction 8228d8f4010208d974e696cea1fc86475ca19cb48243cc831953ea6065544ca2 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), c25349c4ad6c7a59359048ce1f28e5273a6b54783d47d147b785c3c3b1ba5437:1 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
2023-05-10 15:18:31.515 [INF] LNWL: Inserting unconfirmed transaction 8228d8f4010208d974e696cea1fc86475ca19cb48243cc831953ea6065544ca2
2023-05-10 15:18:31.542 [INF] NTFN: New confirmation subscription: conf_id=6, txid=8228d8f4010208d974e696cea1fc86475ca19cb48243cc831953ea6065544ca2, num_confs=6 height_hint=789078
2023-05-10 16:13:38.543 [INF] LNWL: Inserting unconfirmed transaction 8228d8f4010208d974e696cea1fc86475ca19cb48243cc831953ea6065544ca2

Force close tx:
sudo journalctl -u lnd | grep 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691
lnd[3994]: 2023-05-09 05:21:08.301 [INF] CNCT: Broadcasting force close transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691, ChannelPoint(e9a0f06f2cfa858a48d2c727c8d15af2996eee2d8a97fc1bc8bad1505870a552:1): (*wire.MsgTx)(0x400b43a940)({
lnd[3994]: 2023-05-09 05:21:08.316 [INF] LNWL: Inserting unconfirmed transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691
lnd[3994]: 2023-05-09 05:21:08.334 [INF] NTFN: New confirmation subscription: conf_id=2, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691, num_confs=6 height_hint=788873
lnd[3994]: 2023-05-09 05:21:08.384 [INF] SWPR: Sweep request received: out_point=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, witness_type=CommitmentAnchor, relative_time_lock=0, absolute_time_lock=0, amount=0.0000033 BTC, params=(fee=144 blocks, force=true, exclusive_group=0x400d73cd30)
lnd[3994]: 2023-05-09 05:21:08.385 [INF] NTFN: New spend subscription: spend_id=72, outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, height_hint=788873
lnd[3994]: 2023-05-09 05:21:08.386 [INF] NTFN: Dispatching historical spend rescan for outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, start=788873, end=788873
lnd[1174]: 2023-05-09 09:24:45.205 [INF] CNCT: Re-publishing force close tx(183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691) for channel e9a0f06f2cfa858a48d2c727c8d15af2996eee2d8a97fc1bc8bad1505870a552:1
lnd[1174]: 2023-05-09 09:24:46.085 [INF] NTFN: New confirmation subscription: conf_id=1, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691, num_confs=6 height_hint=788906
lnd[1174]: 2023-05-09 09:25:02.025 [INF] SWPR: Sweep request received: out_point=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, witness_type=CommitmentAnchor, relative_time_lock=0, absolute_time_lock=0, amount=0.0000033 BTC, params=(fee=144 blocks, force=true, exclusive_group=0x400738e488)
lnd[1174]: 2023-05-09 09:25:02.863 [INF] NTFN: New spend subscription: spend_id=71, outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, height_hint=788907
lnd[1174]: 2023-05-09 09:25:02.863 [INF] NTFN: Dispatching historical spend rescan for outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, start=788907, end=788907
lnd[35705]: 2023-05-09 11:26:57.578 [INF] CNCT: Re-publishing force close tx(183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691) for channel e9a0f06f2cfa858a48d2c727c8d15af2996eee2d8a97fc1bc8bad1505870a552:1
lnd[35705]: 2023-05-09 11:26:57.609 [INF] NTFN: New confirmation subscription: conf_id=1, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691, num_confs=6 height_hint=788921
lnd[35705]: 2023-05-09 11:27:01.564 [INF] SWPR: Sweep request received: out_point=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, witness_type=CommitmentAnchor, relative_time_lock=0, absolute_time_lock=0, amount=0.0000033 BTC, params=(fee=144 blocks, force=true, exclusive_group=0x4000563b68)
lnd[35705]: 2023-05-09 11:27:01.566 [INF] NTFN: New spend subscription: spend_id=72, outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, height_hint=788921
lnd[35705]: 2023-05-09 11:27:01.567 [INF] NTFN: Dispatching historical spend rescan for outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, start=788921, end=788921
lnd[147435]: 2023-05-09 17:34:39.511 [INF] CNCT: Re-publishing force close tx(183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691) for channel e9a0f06f2cfa858a48d2c727c8d15af2996eee2d8a97fc1bc8bad1505870a552:1
lnd[147435]: 2023-05-09 17:34:39.545 [INF] NTFN: New confirmation subscription: conf_id=1, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691, num_confs=6 height_hint=788950
lnd[147435]: 2023-05-09 17:34:40.900 [INF] SWPR: Sweep request received: out_point=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, witness_type=CommitmentAnchor, relative_time_lock=0, absolute_time_lock=0, amount=0.0000033 BTC, params=(fee=144 blocks, force=true, exclusive_group=0x4003df4b18)
lnd[147435]: 2023-05-09 17:34:41.031 [INF] NTFN: New spend subscription: spend_id=71, outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, height_hint=788950
lnd[147435]: 2023-05-09 17:34:41.032 [INF] NTFN: Dispatching historical spend rescan for outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, start=788950, end=788950
lnd[405824]: 2023-05-10 09:07:36.180 [INF] CNCT: Re-publishing force close tx(183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691) for channel e9a0f06f2cfa858a48d2c727c8d15af2996eee2d8a97fc1bc8bad1505870a552:1
lnd[405824]: 2023-05-10 09:07:36.209 [INF] NTFN: New confirmation subscription: conf_id=2, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691, num_confs=6 height_hint=789040
lnd[405824]: 2023-05-10 09:07:41.849 [INF] SWPR: Sweep request received: out_point=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, witness_type=CommitmentAnchor, relative_time_lock=0, absolute_time_lock=0, amount=0.0000033 BTC, params=(fee=144 blocks, force=true, exclusive_group=0x400209eb98)
lnd[405824]: 2023-05-10 09:07:41.850 [INF] NTFN: New spend subscription: spend_id=68, outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, height_hint=789041
lnd[405824]: 2023-05-10 15:01:59.224 [INF] NTFN: Dispatching confirmed spend notification for outpoint=e9a0f06f2cfa858a48d2c727c8d15af2996eee2d8a97fc1bc8bad1505870a552:1, script=0 17845307e8886858f68355493d201ee105cc93b7b7505be184f08837a50c98c0 at current height=789077: 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691[0] spending e9a0f06f2cfa858a48d2c727c8d15af2996eee2d8a97fc1bc8bad1505870a552:1 at height=789077
lnd[405824]: 2023-05-10 15:01:59.241 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:02:00.479 [INF] NTFN: New confirmation subscription: conf_id=5, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691, num_confs=1 height_hint=789077
lnd[405824]: 2023-05-10 15:02:00.488 [INF] SWPR: Sweep request received: out_point=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, witness_type=CommitmentAnchor, relative_time_lock=0, absolute_time_lock=0, amount=0.0000033 BTC, params=(fee=253 sat/kw, force=false, exclusive_group=<nil>)
lnd[405824]: 2023-05-10 15:02:01.232 [INF] NTFN: Dispatching 1 confirmation notification for txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691
lnd[405824]: 2023-05-10 15:02:01.233 [INF] NTFN: Canceling confirmation notification: conf_id=5, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691
lnd[405824]: 2023-05-10 15:02:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:03:35.149 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:04:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:05:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:06:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:07:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:08:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:09:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:10:35.153 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:11:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:12:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:13:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:14:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:15:35.147 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:16:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:17:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:18:01.502 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:18:31.504 [INF] SWPR: Creating sweep transaction 8228d8f4010208d974e696cea1fc86475ca19cb48243cc831953ea6065544ca2 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), c25349c4ad6c7a59359048ce1f28e5273a6b54783d47d147b785c3c3b1ba5437:1 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[405824]: 2023-05-10 15:18:35.147 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:19:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:20:35.149 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:21:35.149 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:22:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:23:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:24:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:25:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:26:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:27:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:28:35.149 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:29:35.147 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:30:35.149 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:31:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:32:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:33:35.463 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:34:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:35:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:36:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:37:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:38:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:39:10.233 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:39:35.147 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:39:40.261 [INF] SWPR: Creating sweep transaction 7dcfacac2913b6055bb2efc86c189c837e07330b524b7b219cd9b960cb7aa049 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[405824]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[405824]: 2023-05-10 15:40:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:40:39.878 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:41:09.870 [INF] SWPR: Creating sweep transaction de85482422e456753006fe01ce1452c98e9e64cf61b1e396bf8da70baf92368e for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[405824]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[405824]: 2023-05-10 15:41:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:42:35.149 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:43:35.149 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:44:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:45:35.151 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:46:35.149 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:47:35.184 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:48:35.147 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:49:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:50:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:51:35.147 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:52:35.154 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:53:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:54:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:55:35.147 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:56:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:57:35.147 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:58:35.148 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 15:59:35.152 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 16:00:35.149 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 16:01:38.640 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 16:01:41.326 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 16:02:35.605 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 16:03:35.150 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[405824]: 2023-05-10 16:04:22.500 [INF] NTFN: Dispatching 6 confirmation notification for txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691
lnd[405824]: 2023-05-10 16:04:22.502 [ERR] BTCN: Unable to rebroadcast transaction 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: -27: Transaction already in block chain
lnd[1254]: 2023-05-10 16:13:38.073 [INF] LNWL: 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691: tx already confirmed
lnd[1254]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[1254]: 2023-05-10 16:14:02.847 [INF] SWPR: Sweep request received: out_point=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, witness_type=CommitmentAnchor, relative_time_lock=0, absolute_time_lock=0, amount=0.0000033 BTC, params=(fee=253 sat/kw, force=false, exclusive_group=<nil>)
lnd[1254]: 2023-05-10 16:14:02.847 [INF] NTFN: New spend subscription: spend_id=70, outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, height_hint=789082
lnd[1254]: 2023-05-10 16:14:02.847 [INF] NTFN: Dispatching historical spend rescan for outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, start=789082, end=789086
lnd[1254]: 2023-05-10 16:14:02.847 [INF] NTFN: New confirmation subscription: conf_id=2, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691, num_confs=1 height_hint=789077
lnd[1254]: 2023-05-10 16:14:05.237 [INF] NTFN: Dispatching 1 confirmation notification for txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691
lnd[1254]: 2023-05-10 16:14:05.238 [INF] NTFN: Canceling confirmation notification: conf_id=2, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691
lnd[1254]: 2023-05-10 16:14:10.152 [INF] NTFN: Historical spend dispatch finished for request outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198 (start=789082 end=789086) with details: <nil>
lnd[1254]: 2023-05-10 16:14:32.133 [INF] SWPR: Creating sweep transaction 1509610b38b949e9256bb69478756ebba2bb5a51dbdbfbbfaf46ab13c1e15cc0 for 3 inputs (2f7a8821a9407dc0d5abcf1e39dfbd220216a5a68b412134a9ed3771240f64fa:0 (CommitmentAnchor), 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), fae6523d1f69b26a2c3b7953374f5e2c1da7aa5b35bb9de8eb83f8cd4d52df36:1 (CommitmentAnchor)) using 253 sat/kw, tx_weight=1054, tx_fee=0.00000266 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[1254]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[1254]: 2023-05-10 16:22:20.289 [INF] SWPR: Creating sweep transaction 32e26a5a54c529e03ff31c7303eae519f3940ac2e1bcf658247e963154d256df for 2 inputs (2f7a8821a9407dc0d5abcf1e39dfbd220216a5a68b412134a9ed3771240f64fa:0 (CommitmentAnchor), 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor)) using 253 sat/kw, tx_weight=774, tx_fee=0.00000195 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[1254]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[1254]: 2023-05-10 16:38:05.791 [INF] SWPR: Creating sweep transaction e3b315c8a6b7e1f1a754a1a4fc4cf7e238ed0ff95be0afcdec0cff6bd5b1d350 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[1254]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[1254]: 2023-05-10 16:48:20.969 [INF] SWPR: Creating sweep transaction cd1d0c45e3d1bb8bc8b0a62c14e8a3f43d83f9283800f840695d7d5c5df4db66 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[1254]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[1254]: 2023-05-10 17:25:14.881 [INF] SWPR: Creating sweep transaction 06b5836e139186b9c950fe17dc21145135f7d2e15d420f22c167e9bcd12d7f11 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[1254]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[1254]: 2023-05-10 17:27:30.903 [INF] SWPR: Creating sweep transaction 2ba615acd5d29dd536ec5c1ade9ac842cace4b8eedd30b9c1883aff9ef46ef10 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[1254]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[1254]: 2023-05-10 17:49:17.365 [INF] SWPR: Creating sweep transaction 99ba7d6b63ff4c209e6af0086e94cfe8be4e4695c09d74ff954af840b0e8147f for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[1254]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-10 19:51:15.169 [INF] SWPR: Sweep request received: out_point=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, witness_type=CommitmentAnchor, relative_time_lock=0, absolute_time_lock=0, amount=0.0000033 BTC, params=(fee=253 sat/kw, force=false, exclusive_group=<nil>)
lnd[53818]: 2023-05-10 19:51:15.169 [INF] NTFN: New confirmation subscription: conf_id=1, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691, num_confs=1 height_hint=789077
lnd[53818]: 2023-05-10 19:51:15.169 [INF] NTFN: New spend subscription: spend_id=67, outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, height_hint=789117
lnd[53818]: 2023-05-10 19:51:15.170 [INF] NTFN: Dispatching historical spend rescan for outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198, start=789117, end=789119
lnd[53818]: 2023-05-10 19:51:16.566 [INF] NTFN: Dispatching 1 confirmation notification for txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691
lnd[53818]: 2023-05-10 19:51:16.566 [INF] NTFN: Canceling confirmation notification: conf_id=1, txid=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691
lnd[53818]: 2023-05-10 19:51:19.468 [INF] NTFN: Historical spend dispatch finished for request outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198 (start=789117 end=789119) with details: <nil>
lnd[53818]: 2023-05-10 19:51:47.474 [INF] SWPR: Creating sweep transaction 9db7fe56b82c7d57a807fd2e6aa1b862316b2e000fbeefd8ecd8944a13a1ce79 for 3 inputs (2f7a8821a9407dc0d5abcf1e39dfbd220216a5a68b412134a9ed3771240f64fa:0 (CommitmentAnchor), fae6523d1f69b26a2c3b7953374f5e2c1da7aa5b35bb9de8eb83f8cd4d52df36:1 (CommitmentAnchor), 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor)) using 253 sat/kw, tx_weight=1054, tx_fee=0.00000266 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-10 19:57:02.131 [INF] SWPR: Creating sweep transaction 1825e47a807ba4b93888e91f6f86a6d9106cb2c6feaaa5978a6301655b0bf3dd for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 2f7a8821a9407dc0d5abcf1e39dfbd220216a5a68b412134a9ed3771240f64fa:0 (CommitmentAnchor)) using 253 sat/kw, tx_weight=774, tx_fee=0.00000195 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-10 20:02:44.131 [INF] SWPR: Creating sweep transaction 9cdd03aa9d0cc2918669f1cb6c7e489740fdd541f41193ced485cb6402f392c9 for 2 inputs (2f7a8821a9407dc0d5abcf1e39dfbd220216a5a68b412134a9ed3771240f64fa:0 (CommitmentAnchor), 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor)) using 253 sat/kw, tx_weight=774, tx_fee=0.00000195 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-10 20:14:15.648 [INF] SWPR: Creating sweep transaction bb8f87f5319377eb46c3016c56a243f0f6a40f639587a7c9b8f3a77664f27528 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-10 21:13:12.706 [INF] SWPR: Creating sweep transaction 61501afdf4d777cf8a790f222d6c3c71af844ba6d6affeaeae9a69158222e7d9 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-10 22:55:10.984 [INF] SWPR: Creating sweep transaction 35bbafe8ab5c9ec8ef1601a91cc0a2a8778af064fa99f5064fdd21e886ccf03f for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-11 00:46:44.652 [INF] SWPR: Creating sweep transaction 82e35c132c87744810635d9c1fa042ca2c956490edb114f43821335a8a54b38e for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-11 10:19:23.572 [INF] SWPR: Creating sweep transaction 983f70c8266348ec8e47f765130b85b54e628486fc15c620d96411043e4ecbf4 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-12 03:22:12.594 [INF] SWPR: Creating sweep transaction 1fc9158c81608472d6cbf4de5360380b9180559b3381227207f5b4ce6e589d0c for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 3ebfd2426ea08ed5ca3a1028a79cc1a7ca81984251be160311e30002d5755132:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-12 11:00:07.818 [INF] SWPR: Sweep request received: out_point=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:3, witness_type=CommitmentTimeLock, relative_time_lock=288, absolute_time_lock=0, amount=0.04794168 BTC, params=(fee=6 blocks, force=false, exclusive_group=<nil>)
lnd[53818]: 2023-05-12 11:00:07.818 [INF] NTFN: New spend subscription: spend_id=73, outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:3, script=0 f27387567b8ce124f8c23b6490ad18131627a9f7899e06940e17d4a1a26946a3, height_hint=789077
lnd[53818]: 2023-05-12 11:00:07.840 [INF] NTFN: Dispatching historical spend rescan for outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:3, script=0 f27387567b8ce124f8c23b6490ad18131627a9f7899e06940e17d4a1a26946a3, start=789077, end=789364
lnd[53818]: 2023-05-12 11:02:06.330 [INF] SWPR: Creating sweep transaction 1838567b9209113be312640402a8c59671a1f1a591bd8877591e2d735f8137b6 for 1 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:3 (CommitmentTimeLock)) using 10426 sat/kw, tx_weight=534, tx_fee=0.00005567 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]: 2023-05-12 11:02:38.451 [INF] SWPR: Creating sweep transaction 074f7829c78de0ea163aa9a3ae8b57df8678c3a61155865935c88ee239813ec3 for 1 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:3 (CommitmentTimeLock)) using 10426 sat/kw, tx_weight=534, tx_fee=0.00005567 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:3,
lnd[53818]: 2023-05-12 11:04:12.552 [INF] NTFN: Dispatching confirmed spend notification for outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:3, script=0 f27387567b8ce124f8c23b6490ad18131627a9f7899e06940e17d4a1a26946a3 at current height=789366: 1838567b9209113be312640402a8c59671a1f1a591bd8877591e2d735f8137b6[0] spending 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:3 at height=789366
lnd[53818]: 2023-05-12 11:04:12.560 [INF] NTFN: Canceling spend notification: spend_id=73, outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:3, script=0 f27387567b8ce124f8c23b6490ad18131627a9f7899e06940e17d4a1a26946a3
lnd[53818]: 2023-05-13 21:07:48.476 [INF] SWPR: Creating sweep transaction 84c8a4937d64bf28c52a163ec9c133d4fc72782df16b4981f8f5ad50555a03b4 for 2 inputs (183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0 (CommitmentAnchor), 848a47bd95eaee9515033930991329bf318d26bb5c37e6dc48d44e955b526e05:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
lnd[53818]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[53818]: 2023-05-13 21:07:48.688 [WRN] SWPR: input 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0: publishAttempts(10) exceeds MaxSweepAttempts(10), removed
lnd[53818]: 2023-05-13 21:07:48.688 [INF] NTFN: Canceling spend notification: spend_id=67, outpoint=183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0, script=0 68726b7c741d2784aad315d6ac0d7c3560574a14de273c90aac311c770254198
lnd[1159]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,
lnd[1308]:    PreviousOutPoint: (wire.OutPoint) 183bcb752177a63e4ef7a426c996f9f890528aed67df22c1d0cff01349f0f691:0,

And the second sweep tx is nowhere mentioned in LND log. Not sure what else to look for.
Thank you.

Not sure what happened but
lncli listunspent suddenly shows that the original input is now spendable and no longer pending, so I guess it resolved itself.
 "address_type": 4,
                        "address": "bc1pq438xnyuxjnxaaq49f8u9awmp3lc54lqj6asqkfj9rsfjcxge2rsyy48j9",
                        "amount_sat": 2170070,
                        "pk_script": "51200562734c9c34a66ef4152a4fc2f5db0c7f8a57e096bb00593228e09960c8ca87",
                        "outpoint": "c25349c4ad6c7a59359048ce1f28e5273a6b54783d47d147b785c3c3b1ba5437:1",
                        "confirmations": 862

Hi @bitromortac, Thanks for your time and attention on this matter.
Considering your feedback, what could be the best solution to my problem? I noted that the milestone for PR #7599, which you've indicated has resolved the issue, appears to be set for 'v0.16.1'. If memory serves, the bug I'm facing started to show up after I updated my node to version 0.16.x. Is it possible that this problem is an unintended consequence of that PR? I'm eager to find out if there's any way to rectify this. I appreciate your help.

@sogoagain are still stuck in a broadcast loop? I think it would be great to have some more logs containing the errors.

@bitromortac Yes, I'm still stuck in a broadcast loop. Upon my inspection, no noticeable error logs related to the problem I'm facing have come up. Are there any particular keywords I should be looking for in the logs? Thank you for taking the time to look into this issue.

@sogoagain, can you check if your issue is the same as in https://github.com/lightningnetwork/lnd/issues/7708?

@bitromortac, Indeed, my issue appears to align closely with Issue #7708. I intend to keep a close watch on that issue for any updates. If there are additional actions you suggest I should undertake in the meantime, I would appreciate your guidance. Thank you.

Just wanted to update that the issue seems to be resolved. I'll be closing this. Thanks for the help!


2.0 (wip) => 2.0

I fixed a handfull of class names and a few html tags to fit 2.0

Thank-you for this, it was on my todo list but I ran out of time today :)

No problem. Sharing my corrections was the least I could do :)


cppcryptfs-np: Add version <IP_ADDRESS>

This package was not accepted in the scoop-extras bucket because of the dependency on dokany-np (https://github.com/lukesampson/scoop-extras/pull/5305).
This is actually a portable app but I still added the -np suffix because all other apps in the bucket have it.

Haha, I wish Scoop had support for autoupdating multiple files already. 😄
Thank you!


[QUESTION] - How to make a subscription with an UserEvent which is an enum with fields

Hi! I notice there is an example about how to setup a port for polling UserEvent and how to make a subscription with Tick event for a component in the file advanced.md. What I wonder is how to make a subscription with an UserEvent which is an enum with fields for a component. For example, I need to sub UserEvent::GotData(Data) for my component as below:
Sub::new(SubEventClause::User(UserEvent::GotData(Data)), SubClause::Always)
But the complie error is:
expected value, found struct Data
If I give an instance of Data in the Sub function, then there will be no compile error but the subscription has no effect. Could you tell me how to make this kind of subscription?
Many Thanks!

The sub clause match for user events depends on your PartialEq implementation. You can see the example here https://github.com/veeso/tui-realm/blob/main/examples/user_events/user_events.rs

The sub clause match for user events depends on your PartialEq implementation. You can see the example here https://github.com/veeso/tui-realm/blob/main/examples/user_events/user_events.rs

Aha! That is the exact answer I want. A little tricky, but saved some performance then just use SubEventClause::Any. Thanks a lot!
I can close this question now.


Correction for raw affiliation University Rennes, CNRS: UMR 6290, Hôpital Sud

Correction needed for raw affiliation University Rennes, CNRS: UMR 6290, Hôpital Sud
raw_affiliation_name: University Rennes, CNRS: UMR 6290, Hôpital Sud
new_rors: 029a4pp87;02feahw73;036xhtv26
previous_rors: 029a4pp87;02feahw73
works_examples: W4377982129
contact: 20d18290f92a186b3aa871d4fdb3e453:d1f65f088510ba6b5223b993be92d113 @ univ-rennes.fr

This issue was accepted and ingested by the OpenAlex team on 2024-10-10. The new affiliations should be visible within the next 7 days.


Support Yii 2.1.

You can add support for yii 2.1, in the development branch to test it and correct errors,
composer.json:
    "yiisoft/yii2": "~2.0.0|~2.1.0",

Thks,

I believe that requires new branch plus someone who is ready to get messy with Yii2.1
I suggest you make a PR to start with then it can be placed in a different branch


Enhance documentation with more examples

Hi @niksy,
I'm using your npm module stylelint-no-restricted-syntax, that it's using this module as a dependency.
Would be really great, if you can enhance the examples from the Readme, as it's a struggle to use it.
I'm referring to these examples
Type selectors: rule, atrule, decl, comment
Universal selector: *
Attribute selectors: [attr=value], [attr=value], [attr~=value], [attr|=value], [attr^=value], [attr$=value], [attr*=value]
Descendant combinator: rule decl
Child combinator: atrule > rule
Adjacent sibling combinator: rule + rule
General sibling combinator: rule ~ rule
Child pseudo classes (:first-child, :last-child, :nth-child, :nth-last-child, :only-child): rule:first-child
Type pseudo classes (:first-of-type, :last-of-type, :nth-of-type, :nth-last-of-type, :only-of-type): rule:first-of-type
Empty nodes: rule:empty
Matches: :matches(rule, atrule)
Negation: :not(atrule)
How to use the Type selectors, what values can be used inside: rule,atrule,decl,comment.
How many params can be used for example "selector": "decl[prop='z-index']",
Checking out https://postcss.org/api/#declaration  the class Declaration accepts more parameters.
I that possible as well? eg: "selector": "decl[prop='z-index' value='test']",
In my case i want to restrict the usage of extend in less files
Case 1
  .a:extend(.b) {}
Case 2
   .a {
     &:extend(.b);
   }

Here is my config until now.
At the moment i'm checking PostCSS API documentation to figure out what params can be used inside Type selectors.
The first case is handled, not sure how can fix the second case. For sure it can be done with Descendant combinator: rule decl
not sure yet how that translates into a correct syntax
  {
        "selector": "rule[selector='/:extend/ig']", // disallow less extend
        "message": "extend not allowed."
    },
    {
        "selector": "decl[value='extend']",
        "message": "z-index not allowed."
    }

Thanks in advance for your time !

Hi @Andrei-Cornea, thanks for the comment!
I tried to keep documentation to minimum just like ESLint does and I think it covers most of the cases.
As for your questions:

How to use the Type selectors, what values can be used inside?

Any node property value can be used.

How many params can be used for example "selector": "decl[prop='z-index']",
Checking out postcss.org/api/#declaration the class Declaration accepts more parameters.
I that possible as well? eg: "selector": "decl[prop='z-index' value='test']",

You can achieve that just like standard CSS selector: decl[prop='z-index'][value='test']
If you have idea how can I make documentation more detailed, I’m open to changes!

Hi @Andrei-Cornea, thanks for the comment!
I tried to keep documentation to minimum just like ESLint does and I think it covers most of the cases.
As for your questions:

How to use the Type selectors, what values can be used inside?

Any node property value can be used.

How many params can be used for example "selector": "decl[prop='z-index']",
Checking out postcss.org/api/#declaration the class Declaration accepts more parameters.
I that possible as well? eg: "selector": "decl[prop='z-index' value='test']",

You can achieve that just like standard CSS selector: decl[prop='z-index'][value='test']
If you have idea how can I make documentation more detailed, I’m open to changes!

Hi @niksy, thanks for your reply.
This being the first time i with AST syntax maybe was a bit confusing.
What helped a lot was unit tests examples.
Maybe the easiest would be to just add those examples as well here.
The best would be to have an css/scss example as well, to have a better understanding of the use case, if is not too much to ask.
Here is a small example of universal selector, how i see the quick way without css example
Universal selector: *
1.  '* decl'
2. '* [value="lightgreen"]'
3. '* *'

Thanks again for your help.
Best Andrei

Hi @niksy, thanks for your reply.
This being the first time i with AST syntax maybe was a bit confusing.
What helped a lot was unit tests examples.
Maybe the easiest would be to just add those examples as well here.
The best would be to have an css/scss example as well, to have a better understanding of the use case, if is not too much to ask.
Here is a small example of universal selector, how i see the quick way without css example
Universal selector: *
1.  '* decl'
2. '* [value="lightgreen"]'
3. '* *'

Thanks again for your help.
Best Andrei

I could add sentence to check tests for more examples. Does that sound OK to you?

I could add sentence to check tests for more examples. Does that sound OK to you?

Yes, should be fine.

Yes, should be fine.

@Andrei-Cornea I see that you closed this issue, sorry I forgot about it! Did you manage to understand better how this module works?


SmartForm leaves empty array on subschemas, should be removed entirely instead

This is an issue with subschemas. It happens either with a false edit as I describe below, or when you delete all the subrecords.
To recreate the issue, use example-forms from Vulcan-Starter. Add optional: true, to the addresses Array in packages/example-forms/lib/modules/customers/schema.js
Start Vulcan. Add a new customer. Click on the green + button to potentially add an address but then simply dismiss the sub-form by clicking the red - button and then submit with no actual addresses. You will get an empty addresses array in Mongo:
meteor:PRIMARY> db.customers.find({_id:"YM6dGLJkzyDhYXPJf"}).pretty()
{
	"_id" : "YM6dGLJkzyDhYXPJf",
...
	"addresses" : [ ]
}

The preferred result would be no addresses entry in the database. See https://vulcanjs.slack.com/archives/C02L990AF/p1541199732120700 for brief reply from Sacha: "it sounds like we could add a clean-up step somewhere in Form.jsx"

Hi @kevinashworth, see also #2114 . I'd be happy to enhance forms as I have similar needs, however it first the code needs a bit more unit testing and cleanup so we can contribute more safely.


Using v1.0.0-beta for csp

See https://github.com/hpe-storage/csi-driver/issues/45

Thanks for the PR but this is a bug we need to fix in the nimble CSP.  Will address that shortly.


Remove weak_rng

Documentation for the function claims it will return the fastest algorithm
available in Rust, but since its return type is hardcoded to XorShiftRng, it
would be an impossible [breaking-change], when, or if, a faster Rng is added to
Rust.
[breaking-change], since this removes public API. Uses of weak_rng function
can be replaced with random::<XorShiftRng>() to achieve almost the same
behaviour.
This is https://github.com/rust-lang/rust/pull/20773.

I've merged this into the next branch, https://github.com/rust-lang/rand/tree/next. I want to keep master "clean" as a drop-in for std::rand, including whatever minor updates are necessary to track nightly. Once we've collected enough improvements, I'm intending to merge that into master and release 0.2 (or 0.3 or whatever), possibly maintaining a legacy branch for the drop-in 0.1.x releases for a little while or just dropping it entirely (depending how soon the switch happens).

Thanks!


Add option for changing compression level.

Fixes #11.
Options syntax similar to https://github.com/martini-contrib/render was used.

Thanks @EgorMatirov! Sorry for the super long delay!


Extension won't build on macOS

There's a few issues in the build script causing things to fail to build on macOS:

[ ] Version info is being pulled from non-existent source code: https://github.com/cake-build/cake-vscode/blob/develop/build/version.cake#L22
The usual code path that runs on windows is being explicitly skipped and so another code path which is no longer valid is run instead.

[ ] VscePackage command cannot locate vsce that was installed, we need to add ToolPath here on macOS: https://github.com/cake-build/cake-vscode/blob/develop/build.cake#L114
I'm not sure if this is appropriate for linux, but on macOS simply setting ToolPath = "/usr/local/bin/vsce" is a workable solution.

[ ] For some reason Clean is being run AFTER Install-Vsce if I just invoke the Default target.  I'm not sure if this is something weird happening with the Mono Scripting engine and can be ignored once Roslyn support is released or what.

@Redth for the second problem, I think the problem here actually lies with the Cake.VsCode addin.  I think I need to provide alternative tool paths:
https://github.com/cake-contrib/Cake.VsCode/blob/develop/Source/Cake.VsCode/VsceTool.cs#L57

@gep13 alternative tool paths and also add just vsce as a tool name (instead of only vsce.cmd)

@Redth if/when you have a minute, can you take a look at this again?
The latest code on the develop branch now successfully builds on Travis for both Linux and OSX.  Could you test it out locally as well?
And if you are happy, we can close this out.

@gep13 works perfectly here, thanks!

@Redth sweet! Thanks for checking!


RN 0.73 support

Description of changes:

Adds support for RN 0.73
Fixes gradle warnings on uncovered player states within loop
Replaced deprecated RTCEventEmitter ( will be removed in future releases) by RTCModernEventEmitter which has identical functionality and is compatible with Fabric.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Migrating to RTCModernEventEmitter is more complex than it seems; I've decided to drop that specific part of the PR due to the limited documentation on that migration process.


Fix Grammar in Divine Activities for All Generation Description

I have fixed the grammatical errors in Divine Activities for All Generation description.
Fixes #254
This PR is part of GSSoC'23.

conflicting fliles


Do not call addPasswordType() when umounted

This is a delayed call from the debounce logic which can trigger following React warning:
Warning: setState(...): Can only update a mounted or mounting component. This usually means you called setState() on an unmounted component. This is a no-op.

I recommend not to execute anything in the debounce when unmounted.

PS: use componentWillUnmount() for the fix

ping?

Sure.  Makes sense.  If you'd like to submit a PR with the change in the src/ folder, I can compile and deploy.
Thanks.

here you go ... happy with that?

Yep, works for me...  Do you want collaborator access for this repo?

me? thanks for the offer but i doubt i will contribute much. this was just one-off occasion.

np.  I'll try and get it up tonight...  Keep you updated.

any news?

I updated and bumped version with npm.  Let me know if you have any issues...

no, works very well now. all good, thx for cooperating


[stable/openvpn] abitity to add second route for service network

Is this a request for help?:no

Is this a BUG REPORT or FEATURE REQUEST? (choose one):FEATURE REQUEST

Version of Helm and Kubernetes:
Helm Client: v2.9.1, Server: v2.9.1
Kubernetes Client: v1.11.1, Server: v1.11.2"
Which chart:
stable/openvpn
What happened:
We are trying to connect an Azure VM with POD/SVC networks in AKS. For this we install stable/openvpn
helm package in AKS, as an internal load balancer. Internal load balancer receive an internal IP in nodes IP range, for example <IP_ADDRESS>.
In such case connection to PODs/services via VPN does not work, if load balancer IP is inside OVPN_K8S_POD_NETWORK IP range (<IP_ADDRESS>/8)
If we set shorter IP range, for example OVPN_K8S_POD_NETWORK=<IP_ADDRESS>, OVPN_K8S_POD_SUBNET=<IP_ADDRESS>, we get access only to services network or POD network.
POD network: <IP_ADDRESS>/16
SVC network: <IP_ADDRESS>/16
What you expected to happen:
We would like to have an option to create two routes rather than one.
One route for POD network, one for SVC network
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know:
I will submit a patch for this.

option added by https://github.com/helm/charts/pull/7470 and https://github.com/helm/charts/pull/7503


Refactor the dragmove event handler

The dragmove event handler for stage is quite massive. It could be refactored into (at least) four smaller functions by dividing it into:

visual stuff (item highlight (shadow), interaction text)
looping through the items in the object layer
looping through the items in the inventory
the rest of it

I'm not sure it's that massive.


Add MPH units for wind speed

Current output:
<Sopel> Dallas, Texas, US: 34°C (93°F), Clouds, Humidity: 36%, Gentle breeze 4.5m/s (↓)

Desired output:
<Sopel> Dallas, Texas, US: 34°C (93°F), Clouds, Humidity: 36%, Gentle breeze 4.5m/s (10.0mph) (↓)

Or something to that effect! (also perhaps consider switching to km/h for the metric output?)

Agree that km/h would make more sense for metric output. And that a mph option would be useful.


Training speed slower  than Non-local attention

I  found add a module of Non-local attention which just add a little extra time cost about 0.4s each iter. But if I add a CC-attention take R==1 , the train time each iter about 0.7s, and 1.0s if R==2. It's not like the description in your paper.  I dont know why.  Can anyone explain it .

@noobliang Thanks for your attention. The inefficient program implementation results in a slower speed than non-local attention. In term of computation cost and memory usage, the CCNet still have advantages mentioned in the paper.  Looking forward to more efficient program implementation.

@noobliang Thanks for your attention. The inefficient program implementation results in a slower speed than non-local attention. In term of computation cost and memory usage, the CCNet still have advantages mentioned in the paper.  Looking forward to more efficient program implementation.

@noobliang Thanks for your attention. The inefficient program implementation results in a slower speed than non-local attention. In term of computation cost and memory usage, the CCNet still have advantages mentioned in the paper. Looking forward to more efficient program implementation.

Well , thank you reply.  I found it almost useless for my segmentation network， it may be the positive samples of the picture too few.

@noobliang Thanks for your attention. The inefficient program implementation results in a slower speed than non-local attention. In term of computation cost and memory usage, the CCNet still have advantages mentioned in the paper. Looking forward to more efficient program implementation.

Well , thank you reply.  I found it almost useless for my segmentation network， it may be the positive samples of the picture too few.


Warn, don't raise, a double started Pretender

Coverage decreased (-0.5%) to 96.618% when pulling 2961ebc7fa2f5f4b38200c020dcf0aaff160e337 on warn-not-raise-on-double-start into cc496ae925656cec4d2a68fd8f005cf79f189913 on master.

SORRY COVERALLS.


User Profile Picture handling

When a user uploads a profile picture, the profile picture stays in the frontend of the app. A malicious user can steal the profile pictures of the user by routing to the path localhost:3000/assets/public/images/uploads/2.jpg
An example can be seen here: https://juice-shop.herokuapp.com/assets/public/images/uploads/2.jpg
This is presently the profile pic of<EMAIL_ADDRESS>

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@bkimminich Would you want to form a challenge around it. Or do you want to fix this and store the profile pic of the user on the backend?

And also, the username field is vulnerable to script injection attack

I would not consider the user profile pictures a sensitive information worth stealing. They're kind of public - okay, they can be enumerated more easily then e.g. Twitter avatars, but I don't see this as a separate challenge really. Other opinions, @wurstbrot @J12934 @CaptainFreak?
PS: The username vulnerability is already a challenge.