AngularJS ui-router function work with $state.go and not with $location.path

I'm new to AnguLarJs , i'm using ui router , i have a function that work well with state.go() but i can't figure out why this does'nt work with $location.path()
this is my config
.state('customer.customerDetail', {
        url: '/customerdetail',
        templateUrl: 'views/customerDetail.html',
        controller: 'customerDetailCtrl',
        data: {
            pageTitle: 'Customer detail'
        },
        params: {
            selectedCustomer: null,

        },
        resolve: {
            loginRequired: loginRequired,
            loadPlugin: function ($ocLazyLoad) {
                return $ocLazyLoad.load([{
                        files: ['js/plugins/hammer/hammer.min.js']
                    },
                    {
                        files: ['css/customerDetail.css'],
                        cache: false,
                    },
                ]);
            }
        }
    })

i have this function that worked well with $state.go()
$scope.goToCustomerDetail = function (customer) {
    $sessionStorage.setObject('customer', customer);
    $rootScope.$emit("gocustomer", customer);
    $state.go('customer.customerDetail', {
        selectedCustomer: customer
    });
}

but when i change it with $location doesnt work anymore
$scope.goToCustomerDetail = function (customer) {
    $sessionStorage.setObject('customer', customer);
    $rootScope.$emit("gocustomer", customer);
     $location.path('/customer/customerdetail').search({ selectedCustomer : customer });
}

what i'm doing wrong? Thanks :)

Hi, your issue reads like a support question. This github repo is only for bug reports and feature requests. Please try one of the listed Support Channels. Thanks!


ScriptTestsPasses test fails

ScriptTestsPasses test fails when project repository is in path containing # char.
In my case it is e:\#github\Serenity.
I've investigated that the problem source is inside Selenium. See https://github.com/SeleniumHQ/selenium/issues/1938.

Thanks for information. I'm not sure if it is a common practice to use # in file / directory names, and wouldn't recommend anyway.


[QHC-264] Add time_of_flight to Qblox and use it for compiling measure operation

Great job with the addition of TOF!!! I left a couple of comments.
Probably you already have this in your scope but is it planned to add the time of flight for QM in a similar way? I suppose the only thing that needs to change is the quantum_machines_compiler (and other minor adjustments) as the basis is already set.
Additionally in QM we also have smearing (among other different variables on measure), could we also add these on your methodology? I am actually asking because it is QM exclusive so I don't know if (or where) we can do the same as with the time of flight.

Great job with the addition of TOF!!! I left a couple of comments.
Probably you already have this in your scope but is it planned to add the time of flight for QM in a similar way? I suppose the only thing that needs to change is the quantum_machines_compiler (and other minor adjustments) as the basis is already set.
Additionally in QM we also have smearing (among other different variables on measure), could we also add these on your methodology? I am actually asking because it is QM exclusive so I don't know if (or where) we can do the same as with the time of flight.

Time of flight is already implemented in Quantum Machines, natively by them. We already provide the parameter in the runcard.
Smearing is a QM-specific parameter, I don't know if it makes sense or if it is even possible to implement something similar for Qblox.

Great job with the addition of TOF!!! I left a couple of comments.
Probably you already have this in your scope but is it planned to add the time of flight for QM in a similar way? I suppose the only thing that needs to change is the quantum_machines_compiler (and other minor adjustments) as the basis is already set.
Additionally in QM we also have smearing (among other different variables on measure), could we also add these on your methodology? I am actually asking because it is QM exclusive so I don't know if (or where) we can do the same as with the time of flight.

Time of flight is already implemented in Quantum Machines, natively by them. We already provide the parameter in the runcard.
Smearing is a QM-specific parameter, I don't know if it makes sense or if it is even possible to implement something similar for Qblox.

Thank you for the clarification about QM TOF. About smearing, I was referring to QM exclusively (I don't think either that it can be implemented in Qblox) as currently we don't have an option to define this parameter (? at least I haven't seen one) and we should give the user this option in the qp.quantum_machines.measure(). Apologies for the confusion, I realize that this is not the best place for a QM comment XD.
On the other hand once the couple of comments are resolved and this sub-branch can be merged without issue


Support of PouchDB v5.0.0

Do we support PouchDB v5.0.0?
My first test migrating from v4.0.0 wasn't successful.

Yes, there are no incompatibilities between 4.0.0 and 5.0.0. If you found an issue, can you describe in more detail what happened?

with PouchDB V5.0.0
and with the basic test :

var pouch = require('pouchdb');
var pouchRepStream = require('pouchdb-replication-stream');
var fs = require('fs');

var url =<EMAIL_ADDRESS>

   var db = new pouch(url);
    var ws = fs.createWriteStream('output.txt');
    //return db.dump(res, this.replicationOpts)

    return db.dump(ws)
        .then(function(res){
          console.log("success",res);
        }).catch(function(e){
          console.log("error",e);
        });

I have on result.txt only a line :
{"version":"1.2.4","db_type":"http","start_time":"2015-10-08T15:41:05.737Z","db_info":{"db_name":"DBName","doc_count":6,"doc_del_count":1,"update_seq":785,"purge_seq":0,"compact_running":false,"disk_size":8630386,"data_size":39177,"instance_start_time":"1442668989564061","disk_format_version":6,"committed_update_seq":785,"host":"https://api.myapp.com:/couchdb//app-users/","auto_compaction":false,"adapter":"http"}}

I confirmed this works fine with PouchDB 4.0.3, but 5.0.0 crashes after writing the first line without ever resolving or rejecting the Promise.

+1 also not finishing here running PouchDB 5.0.0

fixed by fc17211b55037276626d57a8096782ecca4b125d

Thank you very much for fixing this, I had a poke around the code looking for something obvious but your commit shows there was quite a bit more to it.  Really appreciated!

No prob! The important part turned out to be not passing in the stream object as a constructor param: https://github.com/nolanlawson/pouchdb-replication-stream/blob/c3b2aef90773c3254f6587f246eaf3390d2f46ec/lib/index.js#L37-L40

Awesome, I will try to use<EMAIL_ADDRESS>:+1:.


How to update subscript / relational model in AppSync

I have the following model
type Process @model{
    id: ID!
    ...
    tasks:[Task]! @connection(keyName:"byProcess",fields:["id"])
}

type Task @model
    @key(name:"byProcess",fields:["processID"],queryField:"tasksByProcess"){
    id:ID!
    processID:ID!
    name: String!
    isFinished:Boolean!
    ...
}

This generates me code and I can access it like this
var task1 = Task(id:"34",processID:"12",name:"Test",isFinished:false)
var task2 = Task(id:"56",processID:"12",name:"Test",isFinished:false)
var process = Process(id: "12",..., tasks:[task1,task2])

Now I want to update task1 to isFinished = true
//update directly
process.tasks[0].isFinished = true //error: Cannot assign to property: subscript is get-only.
// first update task model and than assign it to process
task1.isFinished = true
process.tasks[0] = task1 // doesn't work either

How can I get the changes from my subscript 'Task' to my 'Process'?

Hi @chris-mds
Changing Task and then adding to Process will not update the local or backend database. You need to get the Task and then call a save operation on it, then query the Process to get the updated Process containing the Task.

Hi @royjit ,
I will try this solution, when updating at my app works. But unfortunately it doesn't.
I tried the following steps
Creating a simple Task where my variable isFinished = false. This works and it shows up like I expected in DynamoDB.
Now I am fetching this Task. This works as well and I receive all my data.
But now I want to update my Task to isFinished = true and this doesn't work.
var finishedTask = task
finishedTask.isFinished = true
print(finishedTask) // console shows the right task and isFinished is successfully set to true
Amplify.API.mutate(request: .update(finishedTask)){ event in
    switch event{
    case .failure(let error):print(error)
    case .success(let result):print(result) // operation success, but isFinished from my task is still false
    }
...

I tried also Amplify.API.updateMutation ... but this also doesn't updated any value from my task, though the operation was signed as successfully performed

Hi @drochetti,
still doesn't work and I figured out this isn't a problem due to the iOS API, because in the console it doesn't work either looking to my screenshot.

Maybe there is something wrong with the resolver?

Hey @chris-mds, that's odd. Did you change anything in your resolvers? If you're using the default ones it should work.
Also, check the version of the CLI. If the error persists I recommend you cut an issue in the CLI repo.

Hi @drochetti,
found the issue. My conflict resolution flow rejected the update:

Now my question is, why cant we see that issue as en error or feedback from the call and how can I solve it? I can disable conflict detection, but later, when I want to add DataStore I think I will face the same issue?! Any suggestion?

Hey @chris-mds, I couple of points about your latest finding:

When you provision the backend to use DataStore (i.e. enable conflict detection), the schema is annotated with metadata relevant to distributed data reconciliation. Tables are decorated with _version, _lastChangedAt and _deleted. Once that's enabled, using the Amplify.API category with that backend becomes a challenge, which means it's up to the developer to provide those fields. You can read more about that here: https://docs.amplify.aws/lib/datastore/how-it-works/q/platform/ios#writing-data-from-the-appsync-console
As for your question "why cant we see that issue as en error or feedback from the call and how can I solve it?", the conflict resolution is a special type of event and it's not handled as part of the error handling logic. There is a conflictHandler that can be setup and has capabilities such as .applyRemote, .applyLocal and .retry(model) so you can make a decision of what to do with the conflict. Read more here: https://docs.amplify.aws/lib/datastore/conflict/q/platform/ios#custom-configuration

Keep in mind though that in your case the conflict only happened because the _version was missing. Like mentioned on point 1, using Amplify.API alongside with Amplify.DataStore can be challenging, you will have to manage the metadata fields yourself. We do intend to add support for that scenario in the future, but it's not something we're actively working at right now.

Hey @drochetti ,
updating works with the DataStore-save operation.
Would it be a good approach to query and subscribe with API framework and do mutations with DataStore operations?
I need to query with API because I can build my own Queries for relational models using an extension for the GraphQLRequest model.
I know this is some kind of weird, but my customer's environment needs to get (query) data from the backend when they are online and after this they change the location to an place without internet connection and work and mutate the queried data.

I know this is some kind of weird, but my customer's environment needs to get (query) data from the backend when they are online and after this they change the location to an place without internet connection and work and mutate the queried data at this offline location since the end of the day. After working it should sync their mutations to the backend

Haha it doesn't sound weird, it's interesting. Do you mean the DataStore cloud sync engine is not enough to guarantee the offline/online data sync? The scenario you describe is exactly what DataStore attempts to enable by default, so I would like to understand if there's something missing.

I need to query with API because I can build my own Queries for relational models using an extension for the GraphQLRequest model.

Can you elaborate on this? Could you query on the local storage with DataStore.query() instead? Assuming the data is synchronized between the API and the local storage, of course.
From what I can tell so far, it seems like we might have a path forward that doesn't depend on you managing the data between API and DataStore yourself. Maybe there is some requirement nuance I'm missing.

Hi @drochetti ,
I have the feeling I misunderstood something fundamental here lol.
The query operation on DataStore only queries the local storage? So how can I query a list of items from my table with the DataStore API? When I have a table of lets say 100k items, this whole table isn't stored locally?
And how can I list items respectively work with my GSI I extra created with an @connection directive in my schema, so I can query between relations?

@chris-mds

The query operation on DataStore only queries the local storage? So how can I query a list of items from my table with the DataStore API?

Yes, it only queries the local storage, but it also keeps a cloud sync process going when online to make sure the local and remote data are in sync.

When I have a table of lets say 100k items, this whole table isn't stored locally?

By default it syncs all the data the logged user has access to. If you believe you need further optimization, we're actively working on a feature that allows you to specify a filter for a subset of data you need to sync.

And how can I list items respectively work with my GSI I extra created with an @connection directive in my schema, so I can query between relations?
Looking to my schema at my first post, how could I fetch a list of tasks from a specific process, when I only have the Amplify.DataStore.query operation, which only takes a model or model and id as an input?

If you rely on DataStore to query the data locally, you don't even need the GSI. The DataStore.query() is overloaded. You can query by id like you pointed out but you can also query using predicates, for example:
Amplify.DataStore.query(Task.self, where: Task.keys.processID == process.id) {
    // handle result
}

You can read more here: https://docs.amplify.aws/lib/datastore/data-access/q/platform/ios#predicates

Okay now its gettin clearer.
Will wait for the subset filter to use DataStore and will begin with an OnlyOnline-solution and APIPlugin
Thank you for your help @drochetti .

@chris-mds If I may, I would recommend you try using Amplify.DataStore if you're aiming for offline support. I would imagine your development dataset is not too large and you can always optimize the sync query later instead of converting a codebase from API to DataStore.
Good luck in your project!


lost some test token in the wallet?

OS : ubuntu 14.04
I run the qtum wallet in my own machine, and got 10000 QTUM from  @Earlz
(ID: b459f0adeaf6e63d90035f23210d57bdc4434580cb3cbbf92822a0a25175aad8) 。
I also got (131+92+160) QTUM from the Faucet .
(ID: 8913eeb7579577e1580d6dae63051a5174711bdff5540b2f08837fd12fb04fce;
ID: 26c8b558aba644f282e36fa9a03112c190d9a066f5e4fb25cbf0d5fa1e8b4396;
ID: 0e46ed75288c332753aef6829341a7be250a57de5617a6d133c920050680f8da
)
also mining (4+4+4) QTUM
(
ID: 5fb2384aa1a0e68e64197206d4b12e5328416d78c6d67f40ac455f02ce834c9c
ID: c9adbf36da5e049f1daf3f689a486c77507dae673f0c423aa6e795e1630e5403
ID: 7ea5328e91a22ca70e2df2d6df9ec24dba8b66d7e5baffd200324e787ce8e696
)
The total amount should be 10000+131+92+160+4+4+4 = 10395.
But, when I run
./qtum-cli getwalletinfo
{
  "walletversion": 130000,
  "balance": 9507.09198461,
  "stake": 0.00000000,
  "unconfirmed_balance": 0.00000000,
  "immature_balance": 0.00000000,
  "txcount": 10,
  "keypoololdest":<PHONE_NUMBER>,
  "keypoolsize": 100,
  "paytxfee": 0.00000000,
  "hdmasterkeyid": "f98f6dc526d064e83364f5ed7f72b997eef00512"
}

I just have 9507 QTUM in my wallet,  means lost 10395-9507 = 888QTUM.
by testing the transaction, I send QTUM to myself 2 times, every transaction cost 0.00004520 QTUM as fee.
(
ID: 8d4d8b8b6c48f5a21802607c79ea41900989581774c520dec4f4968b93cd7ee2
ID: 254c37d49bdd6bdff8a5a47b0b4beed2cc9e8e94a087f46c5d88543e60b20351
)
one of the self transation, I send 888QTUM to this address
(https://qtum.info/address/QchZm2zLLnn979RYh2ZF3JgiGAjiiSP1Mc)
I wonder If I lost the private key of (QchZm2zLLnn979RYh2ZF3JgiGAjiiSP1Mc) ?
./qtum-cli dumpprivkey "QchZm2zLLnn979RYh2ZF3JgiGAjiiSP1Mc" KxSWWXrRcomCfWNpLhPPSpghFBEr9a8AAvZUzkWHUZZnsUGZjUJm
[dumpprivkey]  shows that I have the private key.
so, I want to know, is this  a bug?
maybe I didn't discribe it very clear,you can ask me any details if needed.

Would you mind uploading your wallet.dat file?

Also try starting qtumd with the command line argument -zapwallettxes=1 and/or -rescan. These should rescan the blockchain for transactions belonging to your wallet and pick up any missing coins. However, this still shouldn't have happened unless you imported or restored a private key backup

I tried the command line argument you recommend, but it didn't work.
This is my wallet file.
wallet.zip

Still have not been able to determine why this happens or reproduce the issue, closing for now


Cancel previous CI runs when new commits are added

GitHub Actions running for previous commits will now be halted when new commits are pushed to a pull request or to main.

This change is

Moved to #261 to verify branch runs on this repo rather than needing to verify on the fork.


Go 12 And Change Authentication to accept string instead of bool

I've added:

go modules to support development on go 12
change authentication in credit card to string instead of bool

This PR is related to issue in #39

Great thanks for the contributions, we'll check. Probably will have to get the versioning first before merging this to master, because it introduces some changes that might incompatible with current master version. Thanks 👍


Add test case for TooManyFunctons fix - #1439

Codecov Report

Merging #1447 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1447   +/-   ##
=========================================
  Coverage     74.62%   74.62%
  Complexity     1716     1716
=========================================
  Files           326      326
  Lines          5171     5171
  Branches        934      934
=========================================
  Hits           3859     3859
  Misses          788      788
  Partials        524      524

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 8e4bad5...65de83c. Read the comment docs.


Support of Reactor's types like Mono and Flux?

I'm building a Spring Boot 2 project with Reactive Web (Spring WebFlux), which relies on Reactor. My services are thus returning Mono<T>s and Flux<T>s.
The problem is that I can't manage to make my GraphQLSchema handle those types correctly.

For example, say I have the following schema:
type Query {
  article(
    id: Long!
  ): Article!
}

type Article {
  id: Long!
  name: String!
}

And the following QueryResolver:
public class QueryResolver implements GraphQLQueryResolver {

  private final ArticleService articleService;

  public QueryResolver(ArticleService articleService) {
    this.articleService = articleService;
  }

  public Mono<Article> getArticle(long id) {
    return articleService.findOneById(id);
  }

}

Building the schema:
GraphQLSchema schema = SchemaParser.newParser()
  .file("schema.graphqls")
  .resolvers(queryResolver)
  .build()
  .makeExecutableSchema();
GraphQL build = GraphQL.newGraphQL(schema).build();

When running a query:
ExecutionResult executionResult = build.execute("...");

I catch the following exception:
TypeClassMatcher$RawClassRequiredForGraphQLMappingException: Type reactor.core.publisher.Mono<my.pkg.Article> cannot be mapped to a GraphQL type!  Since GraphQL-Java deals with erased types at runtime, only non-parameterized classes can represent a GraphQL type.  This allows for reverse-lookup by java class in interfaces and union types.

I then tried to register a SchemaParserOptions.GenericWrapper for the Mono<T> type:
SchemaParserOptions options = SchemaParserOptions.newOptions()
  .genericWrappers(new SchemaParserOptions.GenericWrapper(Mono.class, 0))
  .build();

After having passed these options to the SchemaParser above, when running a query, I now catch the following exception:
ResolverError: Expected source object to be an instance of 'my.pkg.Article' but instead got 'reactor.core.publisher.MonoCompletionStage'

I wanted to try to register a SchemaParserOptions.GenericWrapper for MonoCompletionStage as well, but the class is only visible package-wise.
Any idea how I could proceed?

Just a naive idea of mine: couldn't inheritance be checked when the SchemaParserOptions.GenericWrappers are used? As MonoCompletionStage<T> is a subtype of Mono<T>, registering a SchemaParserOptions.GenericWrapper for Mono<T>could then take into account the subtypes of Mono<T> somehow... Note that I have no idea of the technical involvements of this ;)
In this case, because you're already registering a SchemaParserOptions.GenericWrapper for Publisher<T> if I use .useDefaultGenericWrappers(true), I even wouldn't have to register a SchemaParserOptions.GenericWrapper for Mono<T> as it extends Publisher<T>.

In the meantime, I'm converting my Mono<T> into a CompletableFuture<T>:
public CompletableFuture<Article> getArticle(long id) {
  return articleService.findOneById(id).toFuture();
}

And then converting the query result back into a Mono<T> to make it WebFlux-compliant:
Mono.fromFuture(result);

Little update: I've started playing with @Batched fetchers to avoid "select n+1", it would be pretty elegant if I could simply return a Flux from these! For example,  say one Article is linked to one Blog:
public class ArticleResolver implements GraphQLResolver<Article> {

  private final BlogService blogService;

  public ArticleResolver(ArticleService articleService) {
    this.articleService = articleService;
  }

  @Batched
  public Flux<Blog> getBlog(List<Article> articles) {
    return blogService.findByArticles(articles);
  }

}

In the above example, blogService.findByArticles(articles) returns a Flux<Blog> (pushing as many Blogs as inputted Articles, plus making sure the inputted Articles order matches the the one Blogs have been pushed into the Flux).

A less-but-still elegant API would be to use a Mono, e.g.:
@Batched
public Mono<List<Blog>> getBlog(List<Article> articles) {
  // ...
}

What do you think? I'm afraid all this is going kind of out of scope for graphql-java-tools though, making it quite tight with Reactor...

Wait, thinking back to my original issue, there's something I don't really understand: registering a GenericWrapper for Mono actually successfully validated the schema when creating the GraphQLSchema instance. The issue I then faced was at query execution time, because I guess the engine simply doesn't know how to get the actual wrapped value out of the Mono (more specifically out of the MonoCompletionStage, subtype of Mono), which is kind of expected as I haven't registered any kind of converter, am I wrong?
If this is true, then what's the use case of actually registering custom GenericWrappers? Because the engine won't ever know how to get the actual value out of it, as it's indeed custom... What did I misunderstand here?

Maybe there something to do around MethodFieldResolverDataFetcher#get(...)?
Because, if I understand correctly, this line basically unwraps an Optional (if the returned value is an Optional, indeed), which is basically what could be done for a Mono (i.e. converting it into a Future thanks to Mono#toFuture(), as the engine already knows how to handle Futures).
So maybe, instead of having this hardcoded only for optional for now, we could think of a way for integrating apps to register custom converters, just like you can currently do for GenericWrappers? Then, this Optional conversion could be registered by default, among the possible custom ones.
@apottere, what do you think of all this?


Updated  content/en/releases/version-skew-policy.md

Follow up on #33919 issue.
Updated  content/en/releases/version-skew-policy.md

@kadtendulkar Please update the PR description as
Fixes #33919

Thanks!!

please squash my commits and merge it. Thanks.

/label tide/merge-method-squash

I'm not sure that this is the right fix - see https://github.com/kubernetes/website/issues/33919#issuecomment-1136829928
/hold

Sorry for the confusing messaging, @kadtendulkar

please squash my commits and merge it. Thanks.

Hi @kadtendulkar, although there is a label for prow to squash commits, manually squashing commits is preferred

The PR has been updated according to https://github.com/kubernetes/website/issues/33919#issuecomment-1136829928
/unhold
Preview of updated page:
https://deploy-preview-33920--kubernetes-io-main-staging.netlify.app/releases/version-skew-policy/
/lgtm

Hi @reylejano, I have squashed my commits as @sftim suggested, please merge the PR.

LGTM from https://github.com/kubernetes/website/pull/33920#issuecomment-1137455387 looks good
/lgtm
/approve

/remove-label tide/merge-method-squash

/lgtm
/approve


GLIBCXX version is too new

on older system (ubuntu16.04):
root@a8e8891acba9:/# python
Python 2.7.12 (default, Mar  1 2021, 11:38:31)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tinyfk
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/tinyfk/__init__.py", line 4, in <module>
    from . import _tinyfk
ImportError: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/local/lib/python2.7/dist-packages/tinyfk/_tinyfk.so)

Fixed in https://github.com/HiroIshida/tinyfk/pull/52


Add Xavier University

Computer Science program: https://www.xavier.edu/computer-science/

@sommern First stage of verification passed, official domain is xavier.edu as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@sommern Thank you for your patience while waiting for a review and processing your request. Pull request merged.


Fix some prow configs.

This PR fixes the prow.tekton.dev URL in gubernator (from tekton.dev, which goes to our site),
and also sets up the code coverage job.

/test pull-tekton-pipeline-go-coverage

/hold

/test pull-tekton-pipeline-go-coverage

/hold remove

This is working now! http://storage.googleapis.com/tekton-prow/pr-logs/pull/tektoncd_pipeline/645/pull-tekton-pipeline-go-coverage/1108405000867942400/artifacts/line-cov.html

/hold cancel


Menu on Jest Docs not closing after choosing a topic on mobile

🐛 Bug Report
The bug is on API section page at least. After choosing and clicking a method on mobile menu it doesnt close, staying in front of the documentation even after the url has changed.

To Reproduce
Go to mobile mode on browser, or open Jest docs on your phone.
Click on the menu, next to API Reference.
Expected behavior
After clicking the menu and choosing a section, the menu should close and we should be at that part of the page.

Happy to accept PR fixing that :) either here or in Docusaurus

Docusaurus (on their own site) behaves correctly, so it's something weird with our setup

Id also want to fix that if possible

PR welcome 🙂

Investigated this a little bit and made an issue on Docusaurus: https://github.com/facebook/Docusaurus/issues/1254
It does not appear to be a wrong setup on the Jest side, but an actual bug on some Markdown parsing on the Docusaurus side...

Thanks @Luanf! When they fix and release an update, we'll upgrade on our side and close this issue 🙂

Upstream fix has landed, just waiting for a release now


feat: remove deprecated platform webos

Platforms affected
n/a
Motivation, Context & Description

Remove deprecated/archived platform webos from coho.
This platform no longer is supported and does not recieve updates.
Testing

n/a
Checklist

[ ] I've run the tests to see all new and existing tests pass
[ ] I added automated test coverage as appropriate for this change
[ ] Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
[ ] If this Pull Request resolves an issue, I linked to the issue in the text above (and used the correct keyword to close issues using keywords)
[ ] I've updated the documentation if necessary

Codecov Report

Merging #317 (878aea6) into master (6375e78) will decrease coverage by 1.84%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #317      +/-   ##
==========================================
- Coverage   58.85%   57.02%   -1.84%
==========================================
  Files           8        8
  Lines         491      491
==========================================
- Hits          289      280       -9
- Misses        202      211       +9

Impacted Files
Coverage Δ

src/repoutil.js
68.91% <ø> (ø)

... and 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Preload OCL Files per SCL File Type

Currently the OCL Files need to be loaded every time a SCL File is validated, because there are OCL Files per SCL File Type.
Loading them all once, didn't work, even when the temporary file isn't importing them. They are loading in the OCL Class, so are active.
The idea is to pre-load them per SCL File Type, this way the loading is done once per file type and that OCL can be reused everytime.

Tried loading the OCL Files during startup, but the classes from Eclipse OCL are using a lot of ThreadLocal variables.
This way multiple validation can be done at the same time.
But this means that loading then happens in the startup thread and validation is also done in this thread, meaning the results from 2 validations are stored in the same ThreadLocal variable. So old validation results are also returned and summing up after each time a validation is done.

This is not needed anymore per FileType. The FileSpecific Rules are handle differently in the OCL Files itself.
So we can always load all OCL Files.
But the problem with ThreadLocal stays, so loading at startup still doesn't work.


Make all internal links relative

Making the links relative will make it easier to set up a staging environment as well as (automatically) testing before pushing upstream. Any thoughts?

In this theme, links are relative by default, I think: http://idratherbewriting.com/documentation-theme-jekyll/mydoc/mydoc_hyperlinks.html. Can you say a little more about what you'd like to change?
Automatically testing the html output is definitely a good idea. I was planning to try out https://github.com/gjtorikian/html-proofer, but I'm not yet sure how I'd make it automatic. I agree that ti'd be best to test before pushing upstream. Maybe whenever you run jekyll serve or jekyll build on your local branch?

What I meant was for the inline html. Seems most of the links there are already relative or external. Any reason the ones in index.md aren't?
Broken links would be nice to test for as well.

Thanks for the clarification, and for catching those links in index.md. No good reason why those weren't relative. I just fixed that, so I'll close this issue, but please let me know if you see the problem anywhere else.
And I totally agree that testing for broken links is important. That'll definitely have to be part of #39.


Fix typing error if theme resource not found

This is my mistake, sorry about that :(
@beryllium can you take PR as soon as possible?

Can you release new version?

Good idea. Done! :)

@beryllium thank you! :smile:


R.init works on strings, R.tail doesn't

This is very surprising.
http://bit.ly/1BpkpEk

R.tail should be equivalent to R.drop(1), so this is a bug as far as I'm concerned.

So @davidchambers are you suggesting that drop be changed so that drop(1, 'foo');//=> ['o', 'o']or thattailbe changed so thattail('foo'); //=> 'oo'`?
I agree that it seems logical that they be equivalent.  But I really don't like special-casing what should be list code to also deal with Strings, and I'm not sure we should be changing core functions like tail to match some implementation fall-out of a different function.  Neither of these is documented to work on Strings.  Should we spend much time worrying how they work if users pass Strings?

I'm suggesting that the default implementation of tail should be drop(1).
I find it helpful when writing—and particularly when refactoring code—to think in terms of equivalences. Functional programming increases our ability to do so (by avoiding side effects). I like knowing that two expressions are equivalent. I'm then free to use whichever expression better conveys my intent, or whichever is preferred by the maintainers of a given project.
R.tail and R.drop(1) could form such an equivalence. Unfortunately as its stands they are equivalent when applied to values of one type but not equivalent when applied to values of another type. I can imagine leaving comments on pull requests along the lines of R.drop(1) is better written as R.tail only to have the pull request's author respond to say that she made the change but that tests failed as a result. She or I would then spend a few minutes in the REPL determining the actual behaviour of these functions, would discover the discrepancy, and possibly then raise the issue here.
One option is to provide String-specific versions of the various slice functions:
strTail :: String -> String
strInit :: String -> String
strTake :: Number -> String -> String
strDrop :: Number -> String -> String
strTakeLast :: Number -> String -> String
strDropLast :: Number -> String -> String

All these functions can be derived from slice for both Array and String. I'd far prefer to do this than to have the String-specific functions above.

I'm suggesting that the default implementation of tail should be drop(1).

While I could easily live with that solution, there are two issues to consider:

This solution depends on our public slice, and the fact that it dispatches to to String.prototype.slice for any of this to work.  There is a serious discussion about removing all dispatching except for FantasyLand compatibility.  Both @paldepind and @buzzdecafe have expressed support for this idea.  I disagree, but have lost plenty of similar battles in the past.  If we go down that route, this becomes a more significant maintenance effort.  Obviously we can still implement tail in terms of drop(1), but getting drop to work properly on Strings and lists will be trickier.

We need to be careful about binding ourselves too closely to arrays.  That's all we have, to be sure.  But thinking of our lists as vector-like collections strikes me as the wrong way to go.  I would much rather think of them more like streams.  The best analogies is lists, in the LISP/Scheme or ML/Haskell style of the empty list or a pair consisting of a head and another list for a tail.  So tail seems a fundamental construct, and it really feels more natural to define drop in terms of it.  I know we probably can't do so in the absence of efficient recursion, but I always want us to be suspicious of such inversions.

So tail seems a fundamental construct, and it really feels more natural to define drop in terms of it.

100% agree with that


help: Set sign colours manually

Neovim version (nvim -v)
0.10.2
Neovim distribution
N/A
Description
I am using the nvim gruvbox theme it did not support heading colours with render-markdown.nvim so after some time i figured out how to make my own colours.
This is now inside of my gruvbox theme
overrides = {
      RenderMarkdownH1Bg = { fg = '#fb4934', bg = '', bold = true },
      RenderMarkdownH2Bg = { fg = '#fabd2f', bg = '', bold = true },
      RenderMarkdownH3Bg = { fg = '#b8bb26', bg = '', bold = true },
      RenderMarkdownH4Bg = { fg = '#8ec07c', bg = '', bold = true },
      RenderMarkdownH5Bg = { fg = '#83a598', bg = '', bold = true },
      RenderMarkdownH6Bg = { fg = '#d3869b', bg = '', bold = true },
    },

The only issue is that i can't find the parameter-name of the signs, since they too do not follow the gruvbox theme, so i would like to manually just set them to the correct colours the way i did with the markdown headings.
So the question is how do i manually change the colours for the different signs?

All the highlight information is defined here: https://github.com/MeanderingProgrammer/render-markdown.nvim?tab=readme-ov-file#colors.
Sign highlights are not specified explicitly but in general use the foreground color of the associated object, in this case the heading.
The various HnBg are meant to supply a background color rather than a foreground.
Try modifying your overrides to:
overrides = {
      RenderMarkdownH1 = { fg = '#fb4934', bg = '', bold = true },
      RenderMarkdownH2 = { fg = '#fabd2f', bg = '', bold = true },
      RenderMarkdownH3 = { fg = '#b8bb26', bg = '', bold = true },
      RenderMarkdownH4 = { fg = '#8ec07c', bg = '', bold = true },
      RenderMarkdownH5 = { fg = '#83a598', bg = '', bold = true },
      RenderMarkdownH6 = { fg = '#d3869b', bg = '', bold = true },
},

Thank you that worked a lot better. This removed other issues that came from my "fix" as well.
I am both new to neovim and computer science (I started my first year in computer science this august) so i did not know that i could change treesitter like this. So again thank you for your speedy reply.
When i used your solution though i got some wierd green overlay on every heading. I had to add empty '' strings inside of the backgrounds in my render-markdown.lua file, and then that problem vanished. Thank you very much again.

No problem, and super cool that you're taking an interest in stuff like this so early on.
I would say though that you're not "changing treesitter". The world of highlighting things is to the best of my knowledge a bit loosey goosey.
Treesitter in general is a way to parse languages.
Then on top of that nvim-treesitter assigns common names to different patterns for each language, i.e. variables get assigned to @variable regardless of the language. You can see the full list in :h treesitter-highlight-groups.
Then color schemes implement concrete colors for these common names and voila you get syntax highlighting.
But not all color schemes implement all of the base nvim-treesitter highlights. And additionally plugins allow color schemes to override default behaviors by implementing specific highlights for them.
But which set and what plugins is all up to the individual.

The green background comes from the default behavior of RenderMarkdownH1Bg, which links to DiffAdd which I'm assuming gruvbox implements as green.

Yes that was exactly right! i added the DiffAdd and set the background and foreground to empty and now it is properly transparent with the render-markdown.lua file
Thank you
    overrides = {
      -- Markdown Header Background Overrides with Foreground Colors
<EMAIL_ADDRESS>= { fg = '#fb4934', bg = '', bold = true },
<EMAIL_ADDRESS>= { fg = '#fabd2f', bg = '', bold = true },
<EMAIL_ADDRESS>= { fg = '#b8bb26', bg = '', bold = true },
<EMAIL_ADDRESS>= { fg = '#8ec07c', bg = '', bold = true },
<EMAIL_ADDRESS>= { fg = '#83a598', bg = '', bold = true },
<EMAIL_ADDRESS>= { fg = '#d3869b', bg = '', bold = true },
      ['DiffAdd'] = { fg = '', bg = '' },
    },

This now does not have to be empty anymore
-- render-markdown.lua
backgrounds = {
        'RenderMarkdownH1Bg',
        'RenderMarkdownH2Bg',
        'RenderMarkdownH3Bg',
        'RenderMarkdownH4Bg',
        'RenderMarkdownH5Bg',
        'RenderMarkdownH6Bg',
      },

I will have to read up a bit now on treesitter thank you for the knowledge! :)

May have been a bit quick. adding DiffAdd only worked for the first heading. But i found that if i add these as well then every heading works
      ['DiffChange'] = { fg = '', bg = '' },
      ['DiffDelete'] = { fg = '', bg = '' },

You wouldn't want to disable the diff highlight groups, since those are used in other places. Adding the per level markup headings makes sense, disabling the Diff ones for everyone does not.
I'll leave those decisions to the color scheme author though.

Yeah you are right. I went a little overboard. I commented out the ones for the diffs, and instead made the background colours inside of the render-markdown.lua plugin itself empty again.
-- render-markdown.lua
      backgrounds = {
        '',
        '',
        '',
        '',
        '',
        '',
      },

-- gruvbox.lua
    vim.api.nvim_create_autocmd('FileType', {
      pattern = 'markdown',
      callback = function()
        -- Markdown-specific heading highlights
        vim.api.nvim_set_hl(0<EMAIL_ADDRESS>{ fg = '#fb4934', bg = '', bold = true })
        vim.api.nvim_set_hl(0<EMAIL_ADDRESS>{ fg = '#fabd2f', bg = '', bold = true })
        vim.api.nvim_set_hl(0<EMAIL_ADDRESS>{ fg = '#b8bb26', bg = '', bold = true })
        vim.api.nvim_set_hl(0<EMAIL_ADDRESS>{ fg = '#8ec07c', bg = '', bold = true })
        vim.api.nvim_set_hl(0<EMAIL_ADDRESS>{ fg = '#83a598', bg = '', bold = true })
        vim.api.nvim_set_hl(0<EMAIL_ADDRESS>{ fg = '#d3869b', bg = '', bold = true })

        -- DiffAdd and other Diff groups specifically for Markdown
        -- vim.api.nvim_set_hl(0, 'DiffAdd', { fg = '', bg = '' })
        -- vim.api.nvim_set_hl(0, 'DiffChange', { fg = '', bg = '' })
        -- vim.api.nvim_set_hl(0, 'DiffDelete', { fg = '', bg = '' })
      end,
    })


Can't press ShapeSource on top of UserLocation

Hello,

I have a SymbolLayer located underneath the UserLocation, and I wish the SymbolLayer to be pressable.
But it seems it can't be done: when I press the icon, it is actually the UserLocation which is pressed, and the UserLocation onPress event doesn't have any argument and doesn't have a pointerEvents prop or equivalent.
Is there a way to get to the SymbolLayer ?
Again, great repo, and greater to become, thanks all for the work done !

@mfazekas can you experience the same behaviour ?
I can see on ShapeSource.md that

Source press listener, gets called when a user presses one of the children layers only
if that layer has a higher z-index than another source layers

And I can see that UserLocation is an Annotation, and Annotation is a ShapeSource, so does it mean that we should give a low z-index to UserLocation ? If so, how can we achieve this ?

Having the same issue, was this fixed?

Workaround can be to put a transparent layer on top of the layer in the shape source with a higher index than user location.
We could accept a PR with a prop on UserLocation that disables the on press listener, but I honestly feel like this is a very narrow usecase with a functional workaround.

Hi @kristfal
Thanks for the tip, but I just spent a few hours on it and I don't see how to proceed.
The last step I've done has been to increase the layerIndex of my SymbolLayer while hot reloading, which is working while hot reloading until the layerIndex 196 (don't ask me why !), then at 197 it crashes. At 196, I could see that my SymbolLayer was coming on top of the UserLocation so I was quite happy, but I still couldn't click on it.
But when I reload the app with 196, it crashes directly (even more: it quits unexpectedly and I need to yarn ios again).
So I don't see how to proceed ! If you have one more clue it would be really nice...

@kristfal I don't think this is a narrow usecase... If anyone has custom markers rendered (think of the earthquake example) which are clickable, none can be clicked if they are within a 1inch by 1inch square of UserLocation...

@kristfal I need to move forward on the subject now, this is becoming critical to me... a help would be great if possible !

Workaround can be to put a transparent layer on top of the layer in the shape source with a higher index than user location.
According to this comment on #392 , the layerIndex is still a problem, how could you use it ?

We could accept a PR with a prop on UserLocation that disables the on press listener, but I honestly feel like this is a very narrow usecase with a functional workaround.
How do you disable the onPress listener and not capture the touch press so that it goes to the underlying Symbol ?

Thanks !

@arnaudambro I'm not entirely following your solution - how would you apply that to my code below?
      <MapboxGL.ShapeSource
        id="ShapeSource"
        shape={this.state.featureCollection}
        cluster
        clusterRadius={50}
        clusterMaxZoom={16}
      >
        <MapboxGL.SymbolLayer id="pointCount" />
        <MapboxGL.SymbolLayer
          id="clusteredPoints"
          belowLayerID="pointCount"
          filter={['has', 'point_count']}
          style={layerStyles.clusterIcon}
        />
        <MapboxGL.SymbolLayer
          id="singleIcon"
          filter={['!', ['has', 'point_count']]}
          style={layerStyles.icon}
        />
      </MapboxGL.ShapeSource>

Can you provide the whole code, markers + user-location so that I can test myself ?

@arnaudambro Thank you very much for your help! I'm getting a step closer to what i'm looking for.
With your solution, user is hidden below the symbol so it can not be seen. What I'm trying to do is to have user on the top of the symbol but the user layer not capturing onPress event that way the layer of the symbol could catch the onPress event.
For know I did set a pulse circleRadius larger than my symbol that way the user can still guess where he is located on the map by seeing a part of the pulse circle. Bad UX but better than seeing nothing 😄

@arnaudambro see https://github.com/react-native-mapbox-gl/maps/issues/534#issuecomment-991575646 ;)

Hey guys!
Do you have a fix for this?
I'm adding markers to the map when the user clicks on any place but when the user clicks near of the user location icon, the on press function from the mapview component is not called.

We could accept a PR with a prop on UserLocation that disables the on press listener

That would be really cool to have a prop for this. I don't think I have the skills to implement it - but I wish.

Actually, using renderMode={'native'} seems to resolve this issue in iOS. However, it appears that @mfazekas is going to deprecate that soon.

As a workaround I've used something like this to handle my use case:
async function handleLocationPress() {
  const currentLocation = []; // you current location position (GeoJSON.Position)
  const screenCoordinates = await mapRef.current?.getPointInView(currentLocation);
  const screenPointFeature = feature(
    {
      type: 'Point',
      coordinates: currentLocation
    },
    {
      screenPointX: screenCoordinates?.[0] || 0,
      screenPointY: screenCoordinates?.[1] || 0
    }
  );

  handlePress(screenPointFeature);
}

async function handlePress(feature) {
  const { screenPointX, screenPointY } = feature.properties;

  // Note this only works for the following layers: SymbolLayer, CircleLayer, LineLayer, and FillLayer
  const featureCollection = await mapRef.current?.queryRenderedFeaturesAtPoint(
    [screenPointX, screenPointY],
    null,
    [
      ...layerIdsToQueryOn // string[]
    ]
  );

 return featureCollection;
}

// Use
<Mapbox.MapView
  ref={mapRef}
  style={{ flex: 1 }}
  onPress={handlePress}
>
<UserLocation
  ref={userLocationRef}
  onUpdate={handleUserLocationUpdate}
  minDisplacement={1}
  animated
  visible={locationVisible}
  onPress={handleLocationPress}
/>
{/* Whatever else ShapeSources and content below */}
</Mapbox.MapView>


Enhancement: Tombstone height defines how many elements get set in DOM

Hi, one question. Why when the tombstone is for example 1px I get more nodes in de the DOM and when it's higher I get less?
Although, if for example I set a tombstone with a height of more pixels than the chat messages the chunks of messages that I get are more separated from each other. The transform position its really offsetted. That did not happened on your chat demo (that actually now is not working 😛).
Thanks again!

RecyclerView will get the height of the tombstone, and predict and fill the tombstone according to the sliding distance. In my demo 's animation is working.

Hmmm there is a way to avoid that distance between chunks? Even if means sacrificing the tombstone.
The only way I could remove that it was setting the tombstone to super small height. In that way the incoming items won't have that big separation between each. But the tombstones when they appear are extremely close.

@hazzo This is a problem, I'll try to solve it later.

@hazzo fixed at 0.3.3

Great! Saw it genius!


Improve integration testing docs

Which issue does this PR close?
Re https://github.com/apache/arrow-rs/issues/1398
Rationale for this change
It took me a while to sort out how to run the integration test so I figured I would encode some of that knowledge in docs to assist myself (or others) in the future
What changes are included in this PR?
Update developer docs
Are there any user-facing changes?
No

Codecov Report

Merging #1403 (00b1a2c) into master (afcf304) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1403      +/-   ##
==========================================
- Coverage   83.10%   83.10%   -0.01%
==========================================
  Files         181      181
  Lines       53244    53244
==========================================
- Hits        44249    44246       -3
- Misses       8995     8998       +3

Impacted Files
Coverage Δ

...-testing/src/bin/flight-test-integration-client.rs
0.00% <ø> (ø)

arrow/src/datatypes/datatype.rs
66.40% <0.00%> (-0.40%)
:arrow_down:

parquet_derive/src/parquet_field.rs
66.21% <0.00%> (-0.23%)
:arrow_down:

parquet/src/encodings/encoding.rs
93.52% <0.00%> (-0.20%)
:arrow_down:

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 afcf304...00b1a2c. Read the comment docs.

Thanks for the guidance, and we can run the IT test easier.


Add support for not following HTTP redirects

Please describe your feature request:

When crawling a target, do not follow HTTP redirects. Specifically, if a 301 or 302 redirect response code is returned from the server, do not submit an additional request to the value of the Location header.
Describe the use case of this feature:

I want to be able to use katana to crawl an HTTP target that redirects to HTTPS, and be able to see a 301 response and the corresponding headers in the JSON output. I cannot currently do that, because it appears as though katana automatically follows redirects. Here is an example:
Example of a target that has an HTTP -> HTTPS redirect
 > curl -I "http://projectdiscovery.io"
HTTP/1.1 301 Moved Permanently
...

Example of katana following the redirect:
> echo "http://projectdiscovery.io" | katana -silent -d 1 -jsonl -ob -or | jq
{
  "timestamp": "2023-08-16T11:03:53.534286-07:00",
  "request": {
    "method": "GET",
    "endpoint": "http://projectdiscovery.io"
  },
  "response": {
    "status_code": 200,
    "headers": {
      "nel": "{\"success_fraction\":0,\"report_to\":\"cf-nel\",\"max_age\":604800}",
      "x_region": "us-west-2",
      "server": "cloudflare",
      "cache_control": "public, max-age=0, must-revalidate",
      "last_modified": "Thu, 10 Aug 2023 19:30:18 GMT",
      "x_fallback": "No Fallback",
      "connection": "keep-alive",
      "date": "Wed, 16 Aug 2023 18:03:52 GMT",
      "strict_transport_security": "max-age=0; preload",
      "vary": "Accept-Encoding",
      "link": "<https://framerusercontent.com>; rel=\"preconnect\", <https://framerusercontent.com>; rel=\"preconnect\"; crossorigin=\"\"",
      "x_content_type_options": "nosniff",
      "cf_cache_status": "DYNAMIC",
      "report_to": "{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report\\/v3?s=n2k9Dxr3i%2F4XJarE%2FZgCavnGvuIzI7rQ8wpGgKgXsTcwwIx6uCw0QuoFuSwVe%2BbOsYrGFvAMTCHSJifZZ%2B5RBU%2BDiOY6mPrW3tFyC3tWDsHnPmi2lnHVmg0bGPDIw69g49ALK1w%3D\"}],\"group\":\"cf-nel\",\"max_age\":604800}",
      "x_cache": "Cached",
      "cf_ray": "7f7b98b63ff17e70-LAX",
      "content_type": "text/html"
    },
    "technologies": [
      "HSTS",
      "Cloudflare"
    ]
  }
}

Opened PR #588 for this. Hope this helps!

Thank for looking into this issue and pushing up a solution, @WigzyDev! I very much appreciate you taking the time to look into this 🙏.
Using katana v1.0.4 I am seeing that the -dr flag does properly report the redirect (301 status code) 🎉. But if I set a larger max crawl depth (-d flag) katana still follows the redirects:
> echo "http://projectdiscovery.io" | katana -silent -d 3 -dr
http://projectdiscovery.io
https://projectdiscovery.io/
https://projectdiscovery.io/cdn-cgi/l/email-protection
https://projectdiscovery.io/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js
https://chaos.projectdiscovery.io/
https://blog.projectdiscovery.io/announcing-nuclei-cloud/
https://blog.projectdiscovery.io/
https://blog.projectdiscovery.io/stop-pentesting-start-programming/
https://blog.projectdiscovery.io/the-best-defense-is-a-good-offensive-security-program/
https://blog.projectdiscovery.io/hunting-c2-servers/
https://projectdiscovery.io/requestdemo
https://projectdiscovery.io/nuclei
https://projectdiscovery.io/community
https://projectdiscovery.io/terms
https://projectdiscovery.io/privacy
https://projectdiscovery.io/cloudplatform
https://projectdiscovery.io/aboutus

I would expect katana to not crawl any HTTPS pages when the -dr flag is set, and the target is HTTP (http://projectdiscovery.io).
I'll open up another issue to track this bug.


_on_system_configuration_loaded should not modify system state

Noticed today that when I opened napari-micromanager (manually called _on_system_configuration_loaded because it was already loaded remotely) that the objective position changed from where it already was. This seems to be because the objective_combobox was populated with a list default order but didn't check the current state of the objectives so it ended up calling change_objective.
I have two proposed improvements:

[ ] At the end of init the system state should be queried  to account for the config already being loaded
[ ] refresh_objective and friends should take care to not accidentally change the current state via the callbacks on their widgets.

definitely anything you want to submit that protects potential damage is very welcome and high priority


Package and upload on PyPI

The linter should be conveniently installable via PIP:
$ pip install zalando-name-tbd-swagger-linter

The PyPI package name is still open for discussion ("zalando-restful-api-guidelines-linter" is a bit long :smirk: ).

First version was released: https://pypi.python.org/pypi/restful-api-guidelines-linter
NOTE: I left away the "Zalando" part from the PyPI package name.


bug: REVERT does not return the revert reason

Bug Report
#f03cf627ff871b5795cf561e84720244cf7eca71
Current behavior:
REVERT does not use size to load the proper data from memory
Expected behavior:
REVERT uses all the popped value to load the right amount of data.
Steps to reproduce:
Test against the raised error in test_system_operations::test_revert
Related code:
        // TODO: implement loading of the revert reason based on size value,
        // currently limited by short string size
        let size = popped[0];
        let offset = popped[1];

        // Load revert reason from offset
        let (memory, revert_reason_uint256, gas_cost) = Memory.load(memory, offset.low);
        local revert_reason = revert_reason_uint256.low;

        // revert with loaded revert reason short string
        with_attr error_message("Kakarot: Reverted with reason: {revert_reason}") {
            assert TRUE = FALSE;
        }

Other information:
I don't know the actual limitation of with_attr error_message

Don't forget to update this assertion


backup-azure-backup-faq / implications of changing assigned backup policy

https://docs.microsoft.com/en-us/azure/backup/backup-azure-backup-faq
this FAQ does contain description on the effect on previous VM backup restore points should you change a backup policy, however it would also be ideal if it described the effect on previous VM backup restore points when you move a VM between backup policies in the same Recovery Services vault - i.e. do previous VM backup restore points get adopted by the new backup policy where applicable, or do all previous backup restore points get pruned/deleted
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: efe1b860-8d24-1742-4f20-c3e75cacbba3
Version Independent ID: 2ac226c0-df97-f729-fe09-3d51d61b9083
Content: Azure Backup FAQ
Content Source: articles/backup/backup-azure-backup-faq.md
Service: backup
GitHub Login: @markgalioto
Microsoft Alias: markgal

Thanks for the feedback! We are currently investigating and will update you shortly.

@redwoz Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

Hi, We answered this question here: https://docs.microsoft.com/azure/backup/backup-azure-vm-backup-faq#what-happens-when-i-change-a-backup-policy-on-vms
Hope this helps.

We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


Decide on representation of enum values in OpenAPI3

We should be crisp about the meaning of enums in Cadl in general:

enum is a fixed set of values that can be updated in a new api-version
We may need additional patterns for

enums that will never add values

is this really a pattern?

enums that may add values without changing api-version

can this be represented using example values?

Decide on how enums should be represented in OpenAPI3

Should we bring over any part of x-ms-enum?

I don't mind deferring the work to document how @knownValues is used by the OpenAPI emitter if this design issue is taken up quickly.  But if this design discussion does not happen until March (as the milestone seems to indicate), that means that our documentation is incomplete / incorrect for at least 3 months, and that seems too long to me. Can we move up the date for this design discussion to at least Feb (i.e. we'd discuss in a design meeting in January)? If that's not possible, then I think we should either document the current behavior or remove it so that our docs accurately reflect the behavior of the code.

Just to have it here as well for better visibility for this discussion
https://github.com/microsoft/cadl/issues/189#issuecomment-1362578168

It's kind of hard to follow all the discussion around the topic of extensible enums. What would actually be generated for those extensible properties? I've seen mentioned a few times the x-ms-enum pattern or using anyOf.
For example there is the "zalando" way of doing it like this, which is what I would like to do:
DeliveryMethod:
  type: string
  x-extensible-enum:
    - Parcel
    - Letter
    - Email

There is an ongoing discussion in the OpenAPI specification about this topic. Maybe some comments in there could be a good inspiration for what people are currently using to define extensible enums, and it would be great if at least a few of the more common ones could be achieved with cadl.
https://github.com/OAI/OpenAPI-Specification/issues/1552

This is resolved. The openapi3 emitter generates enums and unions of string values as enum.

@mikekistler how would one generate one of the alternative extensible formats? write a custom emitter?

I don't think you need a custom emitter -- you can just add the extension by hand.
Playground example


broker module not working with Naemon

with nagios4/nagios3 build the log:
[1540218035] Error: Could not load module '/usr/lib/nagios/alerta-neb.o' -> /usr/lib/nagios/alerta-neb.o: undefined symbol: write_to_all_logs
[1540218035] Error: Failed to load module '/usr/lib/nagios/alerta-neb.o'.

try make naemon && make install :)


Mangalib don't load pages

Source information
MangaLib 1.4.100
Source language
Russian
Steps to reproduce

Update parser
Open any title on mangalib
Try to open any chapter (in app or webview)

Expected behavior
You can read any chapter of any title
Actual behavior
In app you that it can't load image
On webview you see 404

Mihon/Tachiyomi version
Beta r6710
Android version
Android 13
Other details
Same problem on HentaiLib, butb on hentailib i  can download chapters
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 0.15.3.
[X] I have updated all installed extensions.
[X] I have tried the troubleshooting guide.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

You need to change the domain in the settings to test-front.mangalib.me. Then you need to log in to this site and close the application and disable the process. Then use this guide to migrate title from old lib to new lib. This guide is the same for both Mangalib and HentaiLib and Yaoilib.

You need to change the domain in the settings to test-front.mangalib.me. Then you need to log in to this site and close the application and disable the process. Then use this guide to migrate title from old lib to new lib. This guide is the same for both Mangalib and HentaiLib and Yaoilib.

Ok, changing domain helps for 404 error, but i can't load any page in app. And i also migrate all titles

So complete solution is this:

Change domain in extension setting to https://test-front.mangalib.me
Change image server to compress (or test)
Restart the app
Profit


"OperatingSystem" Library keywords "Copy Directory" has some unpredictable problems.

Here is an example:
*** Settings ***
Library    OperatingSystem
*** Test Cases ***
demo
Copy Directory    dir1/subdir1    dir2/
when dir2 is not exists. "Copy Directory" will first create dir2  but will no longer copy subdir1 to the dir2.
I hope it can create dir2 first when dir2 is not exists, and then copy subdir1 to the dir2.

I think that there is no bug here, or that there is room for improvement (at least in docs with examples).
If you Copy Directory    dir1/subdir1    dir2/ it will create dir2/ and copy the contents of subdir1 into it (and also any subdirs and files it contains). To do what you want you must Copy Directory    dir1/    dir2/. Of course, that there is the inconvenience of also copying any files inside dir1.
I have also tried Copy Directory    dir1/subdir1    dir2/subdir1 and got dir2/subdir2 with dir1/subdir1 files at this level.
I finally achieved what you wanted, with:
Copy Directory    dir1/subdir1/    dir2/subdir1/
(notice the trailing / in directory names)
(tested in Linux x64 with RF 3.0b1)

Test Environment:
Robot Framework 3.0.dev20151119 (Python 2.7.4 on linux2)
copy.robot
*** Settings ***
Library    OperatingSystem
*** Test Cases ***
demo
Copy Directory    ./dir1/subdir1    ./dir2
subdir1 is empty. and dir2 is not exist
before run:
.
├── copy.robot
└── dir1
└── subdir1
after run pybot copy.robot
.
├── copy.robot
├── dir1
│   └── subdir1
└── dir2
......
Which I hope dir2 has subdir subdir1.

This cannot be changed for various reasons:

Copy Directory behaves exactly like cp command in this regard, and I assume copy on Windows works the same way. This is by design.
The behavior is even documented: "If the destination exists, the source is copied under it. Otherwise the destination directory and the possible missing intermediate  directories are created."
Even if we agreed that the behavior should be changed, the change would be backwards incompatible and would require a deprecation period. That would add a lot of extra work.

There is also a simple workaround to create needed intermediate directories first:
*** Test Cases ***
Demo
    Create Directory    dir2
    Copy Directory    dir1/subdir1    dir2


Unused region argument from S3 constructor

$region argument is never used and is confusing
https://github.com/zendframework/zf1/blob/master/library/Zend/Service/Amazon/Abstract.php#L81

@sshilko
Sorry, but I can not found a signed CLA.

i'm on it, but sick atm. will take few days.

just sent out the CLA to<EMAIL_ADDRESS>

@weierophinney
Can you look after the CLA? Thanks!

i did sent an scanned signed CLA as required in good resolution and etc @weierophinney


[bug]: Unknown Unconfirmed Balance

Background
I folks, am running LND as a router. I have unconfirmed balance and not really sure what's happening. Haven't made any channel opens or blockchain payments since way before this issue came up. So I think it must be related to lnd closing a channel.
Here's the relevant data:
$ lncli walletbalance | grep uncon
    "unconfirmed_balance": "1051070",
            "unconfirmed_balance": "1051070"
$ lncli listunspent --unconfirmed_only
{
	"utxos": [
		{
			"address_type": 4,
			"address": "bc1pgptzpw0jr635psy7z4wzm5e74sqlmf96wfqe0uzd9jvpwjjw0adqnek4jc",
			"amount_sat": 1051070,
			"pk_script": "5120405620b9f21ea340c09e155c2dd33eac01fda4ba724197f04d2c98174a4e7f5a",
			"outpoint": "3bc2fa79c945da5f5d457954a2235678ad3e1c1b3a3d7cbd831cff14984cab97:0",
			"confirmations": 0
		}
	]
}
$ lncli pendingchannels
{
    "total_limbo_balance": "0",
    "pending_open_channels": [
    ],
    "pending_closing_channels": [
    ],
    "pending_force_closing_channels": [
    ],
    "waiting_close_channels": [
    ]
}

The relevant transaction doesn't appear on public trackers. Any idea what happened and how to fix?
Your environment

version of lnd

$ lnd --version
lnd version 0.15.2-beta commit=v0.15.2-beta

which operating system (uname -a on *Nix)

$ uname -a
Linux ip-172-31-22-39 5.18.12-1-ec2 #1 SMP PREEMPT_DYNAMIC Sat, 16 Jul 2022 21:17:41 +0000 x86_64 GNU/Linux

(Modified arch linux)

version of btcd, bitcoind, or other backend
(neutrino backend)

any other relevant environment details
Happy to grep some logs if you can give pointers. The ERR logs are a bit noisy. Here's the tail end:

Nov 02 07:22:59 [REDACTED_IP] lnd[265812]: 2022-11-02 07:22:59.278 [ERR] HSWC: Unhandled error while reforwarding htlc settle/fail over htlcswitch: UnknownNextPeer
Nov 02 07:23:04 [REDACTED_IP] lnd[265812]: 2022-11-02 07:23:04.825 [ERR] HSWC: UnknownNextPeer
Nov 02 07:23:04 [REDACTED_IP] lnd[265812]: 2022-11-02 07:23:04.825 [ERR] HSWC: Unhandled error while reforwarding htlc settle/fail over htlcswitch: UnknownNextPeer
Nov 02 07:46:13 [REDACTED_IP] lnd[265812]: 2022-11-02 07:46:13.491 [ERR] HSWC: insufficient bandwidth to route htlc
Nov 02 07:46:13 [REDACTED_IP] lnd[265812]: 2022-11-02 07:46:13.491 [ERR] HSWC: Unhandled error while reforwarding htlc settle/fail over htlcswitch: insufficient bandwidth to route htlc
Nov 02 07:46:18 [REDACTED_IP] lnd[265812]: 2022-11-02 07:46:18.812 [ERR] HSWC: insufficient bandwidth to route htlc
Nov 02 07:46:18 [REDACTED_IP] lnd[265812]: 2022-11-02 07:46:18.812 [ERR] HSWC: Unhandled error while reforwarding htlc settle/fail over htlcswitch: insufficient bandwidth to route htlc
Nov 02 07:52:31 [REDACTED_IP] lnd[265812]: 2022-11-02 07:52:31.461 [ERR] HSWC: insufficient bandwidth to route htlc
Nov 02 07:52:31 [REDACTED_IP] lnd[265812]: 2022-11-02 07:52:31.461 [ERR] HSWC: Unhandled error while reforwarding htlc settle/fail over htlcswitch: insufficient bandwidth to route htlc
Nov 02 07:58:37 [REDACTED_IP] lnd[265812]: 2022-11-02 07:58:37.418 [ERR] LTND: Unable to lookup witness: no witnesses

Hi @WalterSmuts! Thanks for opening the issue :)
On first glance, this looks very similar to #6367, #6231, #6498, #6434
Could you perhaps grep your logs for the transaction ID? (3bc2fa79c945da5f5d457954a2235678ad3e1c1b3a3d7cbd831cff14984cab97)

$ journalctl -u lnd | grep 3bc2fa79c945da5f5d457954a2235678ad3e1c1b3a3d7cbd831cff14984cab97
Oct 24 10:36:20 [REDACTED_IP] lnd[265812]: 2022-10-24 10:36:20.526 [INF] SWPR: Creating sweep transaction 3bc2fa79c945da5f5d457954a2235678ad3e1c1b3a3d7cbd831cff14984cab97 for 2 inputs (1223529f41409200453b3452a5db8ff4de0145ac8be222100566d3c209a2c3f4:0 (CommitmentAnchor), 67426e4cbf40a685597450c68f29eb4f7a4d9979eb8eb529a2bb7acdf222153d:0 (TaprootPubKeySpend)) using 1803 sat/kw, tx_weight=725, tx_fee=0.00002501 BTC, parents_count=1, parents_fee=0.00001128 BTC, parents_weight=1288
Oct 24 10:36:26 [REDACTED_IP] lnd[265812]: 2022-10-24 10:36:26.733 [INF] LNWL: Inserting unconfirmed transaction 3bc2fa79c945da5f5d457954a2235678ad3e1c1b3a3d7cbd831cff14984cab97

interesting. Is your channel with outpoint 67426e4cbf40a685597450c68f29eb4f7a4d9979eb8eb529a2bb7acdf222153d:0 still listed as open in your listchannels output?
Do you recall trying to close this channel? Could you maybe also grep a few logs from above the ones you just posted for this channels outpoint (and perhaps for the channel ID)

interesting. Is your channel with outpoint 67426e4cbf40a685597450c68f29eb4f7a4d9979eb8eb529a2bb7acdf222153d:0 still listed as open in your listchannels output?

Nope, don't think so.
lncli listchannels  | grep 67426e4cbf40a685597450c68f29eb4f7a4d9979eb8eb529a2bb7acdf222153d | wc
      0       0       0

$ lncli closedchannels  | grep 67426e4cbf40a685597450c68f29eb4f7a4d9979eb8eb529a2bb7acdf222153d | wc
      1       2     101

Do you recall trying to close this channel?

Definitely not personally. Could be peer-initiated or a force-close by lnd. Atleast that's what I think.

Could you maybe also grep a few logs from above the ones you just posted for this channels outpoint (and perhaps for the channel ID).

Not sure  which channel you're referring to.

Alright - chatted to the OP offline & we found that the associated channel has been closed but the sweep tx did not broadcast correctly it seems and that is what is showing up in LND.
@WalterSmuts, you are running with a neutrino back-end correct? Would be useful to see some more logs -> my suspicion is that LND gave the tx to neutrino and then neutrino didnt broadcast it properly...
Perhaps would help to turn on debug logs & restart so that the tx is given to neutrino again for broadcast

The OP sent me some logs after turning on debug level. Can confirm that:

LND re-sends the tx to neutrino LNWL: Successfully rebroadcast unconfirmed transaction
Neutrino sends an INV with the tx to a bunch of peers BTCN: Sending inv
The peers to ask the OP's node for the tx BTCN: Received getdata
The OP's node sends the tx BTCN: Sending tx

Alrighty! getting closer to the issue:
Tried to submit the tx to the mempool and got:
error code: -25
error message:
bad-txns-inputs-missingorspent

The output from listchaintxns shows the following:
  "label": "0:sweep",
            "previous_outpoints": [
                {
                    "outpoint": "1223529f41409200453b3452a5db8ff4de0145ac8be222100566d3c209a2c3f4:0",
                    "is_our_output": false
                },
                {
                    "outpoint": "67426e4cbf40a685597450c68f29eb4f7a4d9979eb8eb529a2bb7acdf222153d:0",
                    "is_our_output": true
                }
            ]

The first tx is not a valid tx

miiiight have to do with the fact that someone else swept the anchor output which then invalidated our own sweep of the anchor: https://blockstream.info/tx/078c3357606d7d959e9e5d3b70409971880c384886511c0b5d333b6604ea521d?input:12

Issue still persisting...
@Roasbeef I believe https://github.com/lightningnetwork/lnd/pull/6274 is supposed to solve this issue? Any idea why it's not working?

I have this issue as well
lncli -p boltcard walletbalance | grep uncon
    "unconfirmed_balance": "6536184",
            "unconfirmed_balance": "6536184"

{
	"utxos": [
		{
			"address_type": 4,
			"address": "bc1pg68tner0yukcra78gtrsj7remuf0vnsdd462gd7fg0u3v2rtnspsmnwsgj",
			"amount_sat": 1471233,
			"pk_script": "5120468eb9e46f272d81f7c742c7097879df12f64e0d6d74a437c943f916286b9c03",
			"outpoint": "f061053dc0dbbc04fc89dd38dd5ea794992e7cab0eb8cd9d27c06add5e5b3429:0",
			"confirmations": 0
		},
		{
			"address_type": 4,
			"address": "bc1pj3jl7jzg0drqwpqkflemp9cc582vrjkfvd2xepwz7vs2a7tzm40qn85854",
			"amount_sat": 1974652,
			"pk_script": "51209465ff48487b460704164ff3b09718a1d4c1cac963546c85c2f320aef962dd5e",
			"outpoint": "e9e76d85e2eccc466fe70565544de5c4cccbbe1da1400c0b06d4eddbe0d99bde:0",
			"confirmations": 0
		},
		{
			"address_type": 4,
			"address": "bc1pjtlzgmxj7gx7ncjhd9d945xez6g2nn5v6cfcl6df7zkm9jj6awqsnyp458",
			"amount_sat": 1974505,
			"pk_script": "512092fe246cd2f20de9e257695a5ad0d91690a9ce8cd6138fe9a9f0adb2ca5aeb81",
			"outpoint": "703a0b1dd2a7904edcf84b10b48215ae6895e7c66d21c209028836f1aef72aab:0",
			"confirmations": 0
		},
		{
			"address_type": 4,
			"address": "bc1pa3jkv94fjg653mjm8hnarzvpca4anveyddey279hjrqumju63jqqz7zf5c",
			"amount_sat": 465929,
			"pk_script": "5120ec656616a9923548ee5b3de7d18981c76bd9b3246b724578b790c1cdcb9a8c80",
			"outpoint": "1443d232358b56c87bcab6a37c2cda6ab5740d1ff50207c2ea10009536a7f648:0",
			"confirmations": 0
		},
		{
			"address_type": 4,
			"address": "bc1p83v0adgwq3uq2jhwysv6hes47ytzkv7vxqzz0m7agtqplc50m8jqmqsmzg",
			"amount_sat": 649865,
			"pk_script": "51203c58feb50e0478054aee2419abe615f1162b33cc300427efdd42c01fe28fd9e4",
			"outpoint": "261f965ce0c767a11e27f7c224777ae32bffc8879ecf31a7299a1c7ed835de5a:0",
			"confirmations": 0
		}
	]
}

using the command
lncli sendcoins --sweepall --min_confs 0 --addr bc1q....xxx

seems to have collected all of the zero conf transactions into one new transaction
fingers crossed

Thanks for posting Rob, please let us know what the result is.

Same problem, except now i have 1 zero confirmation transaction stuck and it doesn't seem to have been broadcast by nutrino either!

well the created transaction seems to have a negative amount. that cant be right
{
            "tx_hash": "2ce2b8d0c014f133eb0cbb5c051c40e5459fabf2b5aae3516d23265d12b13c06",
            "amount": "-6308",
            "num_confirmations": 0,
            "block_hash": "",
            "block_height": 0,
            "time_stamp": "1668584398",
            "total_fees": "6308",
            "dest_addresses": [
                "bc1qte75zsmmdvn4rhppuxqxtaxqh7dlmk886lkcwz"
            ],
            "output_details": [
                {
                    "output_type": "SCRIPT_TYPE_WITNESS_V0_PUBKEY_HASH",
                    "address": "bc1qte75zsmmdvn4rhppuxqxtaxqh7dlmk886lkcwz",
                    "pk_script": "00145e7d41437b6b2751dc21e18065f4c0bf9bfdd8e7",
                    "output_index": "0",
                    "amount": "7208118",
                    "is_our_address": true
                }
            ],
            "raw_tx_hex": "0200000000010729345b5edd6ac0279dcdb80eab7c2e9994a75edd38dd89fc04bcdbc03d0561f0000000000000000000de9bd9e0dbedd4060b0c40a11dbecbccc4e54d546505e76f46ccece2856de7e9000000000000000000ab2af7aef136880209c2216dc6e79568ae1582b4104bf8dc4e90a7d21d0b3a7000000000000000000048f6a736950010eac20702f51f0d74b56ada2c7ca3b6ca7bc8568b3532d243140000000000000000005ade35d87e1c9a29a731cf9e87c8ff2be37a7724c2f7271ea167c7e05c961f26000000000000000000fdb1250ec5b1fed711cb3f2727ca29682f90e6e4811d34aef590fc91765b973e000000000000000000f2f9124b32aeae3709c8f098c74cf2da9294d2ba7af2fef22e25d0a9ee42594100000000000000000001b6fc6d00000000001600145e7d41437b6b2751dc21e18065f4c0bf9bfdd8e7014009822a3c929d74b26a3cd9721d0df093ed3d9196174c40e2cac11410c1a253fb0cc706ae3930980690dca37759e6c800155fbb12e3f6fe2245542d557eda2fd401401cc0411531836c0f99f4e6d0311238582a35b31df4819fec5e45d87f3474f1183a6e2ee54fcdf736556976fb516ad10c6213e24fac9500ed1c578ff867c3fe41014082e65b25aeb916039629ec4856a53a18031e2d8b9a2121695d339530d1cb28efa129dfb3f14b5ac6638c64182af119d4808e3f7c94d1a1e3858334df919a18390140877307ada1a76f413260cd37fbb1f3a00c0698fa9f9fe1e08235f1afc1ceb575cbcee5bd68112825d7d66514541c385eee8d0c2b5034386c0b524dc63b03061801400e556a8ef19fb8dffad81980962b5a27722678521137f4cb6771f9b642f4d89b8d3cccaa80033fc33564a119e9e2a657f2df8a7e9c75560e99841289ba4cdeb10140347dc410e448177c88e339b7de00871042f7440999586676be9b189530177be24f2a111dde9854b80438b1ea4fc6f430dd255eb99b17187eec55952fc8798e990140ec27297f201857112184a88c0644dfd3a29046e747f08dacf4f21b3015a8a29c4251f182ea96cb87ef5bfbc178243d7285b5e7ea6a475d1c4c2707e1cbc1cf4203a60b00",
            "label": "external"
        }

I've tried broadcasting one of the raw transactions from my original message
02000000000102fd1d8d2fb559d6436a45d12bcdae0b17863188b0bd1a2df046b139e41149a07801000000000000000098383cb259e631f6c19b9ad79ab5d60aeea25bb8d00ef0f823165a99cf4c924f00000000000000000001091c070000000000225120ec656616a9923548ee5b3de7d18981c76bd9b3246b724578b790c1cdcb9a8c8002473044022010b57190fca53a8d89ffd15b1e8beff7302cde78f948aecc34aec50295d96ee902205d8263441ebcd5bb81d0d7a91a556111d31e908daa78de0fb0aed380e905e9c4012821024c821848f3b80302c5625d09ef5b59c1951725cab223d948584f48c70e825f96ac736460b2680140bbffbbabe064fb012f98bed23d7b96b79d728fc59b4df8bba89df08b27b3d3f113ebe932646c1ffafc03d9e545afa4b40d887847ab42488cd1170c62a90f5d10209c0b00

Error is "bad-txns-inputs-missingorspent"

Got two more stuck transactions:
$ lncli listunspent --unconfirmed_only
{
	"utxos": [
		{
			"address_type": 4,
			"address": "bc1p3g7zgu2teq5shu89jflnrzadl4869ft5pl4wl0ppyu43ry07cseqndfkjm",
			"amount_sat": 1113186,
			"pk_script": "51208a3c24714bc8290bf0e5927f318badfd4fa2a5740feaefbc21272b1191fec432",
			"outpoint": "6cb4874ec6bc654fe7f10346d0edb7fee17acbb1fb4df964c8e03d9a4ba97d2b:0",
			"confirmations": 0
		},
		{
			"address_type": 4,
			"address": "bc1ph0c0c9v3en8k9d003e2rtqlpnpqnuk020rcyep96035we5kfwsuqne96em",
			"amount_sat": 486858,
			"pk_script": "5120bbf0fc1591cccf62b5ef8e543583e198413e59ea78f04c84ba7c68ecd2c97438",
			"outpoint": "f3a7d850701d46ee23affb31d8d9831453323b9be710514e9c28ed5ad20a0d52:0",
			"confirmations": 0
		},
		{
			"address_type": 4,
			"address": "bc1pgptzpw0jr635psy7z4wzm5e74sqlmf96wfqe0uzd9jvpwjjw0adqnek4jc",
			"amount_sat": 1051070,
			"pk_script": "5120405620b9f21ea340c09e155c2dd33eac01fda4ba724197f04d2c98174a4e7f5a",
			"outpoint": "3bc2fa79c945da5f5d457954a2235678ad3e1c1b3a3d7cbd831cff14984cab97:0",
			"confirmations": 0
		}
	]
}```

Added explicit peers about a month ago:
[neutrino]
neutrino.addpeer=btcd-mainnet.lightning.computer
neutrino.addpeer=mainnet1-btcd.zaphq.io
neutrino.addpeer=mainnet2-btcd.zaphq.io
neutrino.addpeer=mainnet3-btcd.zaphq.io
neutrino.addpeer=mainnet4-btcd.zaphq.io

This didn't fix anything but since then I haven't accrued any new unconfirmed tx's:
$ lncli listunspent --unconfirmed_only
{
	"utxos": [
		{
			"address_type": 4,
			"address": "bc1p3g7zgu2teq5shu89jflnrzadl4869ft5pl4wl0ppyu43ry07cseqndfkjm",
			"amount_sat": 1113186,
			"pk_script": "51208a3c24714bc8290bf0e5927f318badfd4fa2a5740feaefbc21272b1191fec432",
			"outpoint": "6cb4874ec6bc654fe7f10346d0edb7fee17acbb1fb4df964c8e03d9a4ba97d2b:0",
			"confirmations": 0
		},
		{
			"address_type": 4,
			"address": "bc1ph0c0c9v3en8k9d003e2rtqlpnpqnuk020rcyep96035we5kfwsuqne96em",
			"amount_sat": 486858,
			"pk_script": "5120bbf0fc1591cccf62b5ef8e543583e198413e59ea78f04c84ba7c68ecd2c97438",
			"outpoint": "f3a7d850701d46ee23affb31d8d9831453323b9be710514e9c28ed5ad20a0d52:0",
			"confirmations": 0
		},
		{
			"address_type": 4,
			"address": "bc1pgptzpw0jr635psy7z4wzm5e74sqlmf96wfqe0uzd9jvpwjjw0adqnek4jc",
			"amount_sat": 1051070,
			"pk_script": "5120405620b9f21ea340c09e155c2dd33eac01fda4ba724197f04d2c98174a4e7f5a",
			"outpoint": "3bc2fa79c945da5f5d457954a2235678ad3e1c1b3a3d7cbd831cff14984cab97:0",
			"confirmations": 0
		}
	]
}

I should add my issue was solved by running btcd in rescanning mode.

I ran lnd with --reset-wallet-transactions, waited for LNWL: Finished rescan for. Removed the second two unconfirmed tx, first one still there:
$ lncli listunspent --unconfirmed_only
{
	"utxos": [
		{
			"address_type": 4,
			"address": "bc1p3g7zgu2teq5shu89jflnrzadl4869ft5pl4wl0ppyu43ry07cseqndfkjm",
			"amount_sat": 1113186,
			"pk_script": "51208a3c24714bc8290bf0e5927f318badfd4fa2a5740feaefbc21272b1191fec432",
			"outpoint": "6cb4874ec6bc654fe7f10346d0edb7fee17acbb1fb4df964c8e03d9a4ba97d2b:0",
			"confirmations": 0
		}
	]
}```

I seem to be having the same issue.  sweeper went nuts with a bunch of txns which never go into mempool until 100% of UTXO was showing as unconfirmed.  I did a rescan, now 2 remain.
"utxos": [
                {
                        "address_type": 4,
                        "address": "bc1pfec57mkv3n90xpa3c379rds72ru9ldydkmjanz37kkg9crjxgxpqrvtzpg",
                        "amount_sat": 2076264,
                        "pk_script": "51204e714f6ecc8ccaf307b1c47c51b61e50f85fb48db6e5d98a3eb5905c0e464182",
                        "outpoint": "53085820a65121739be6ffb067aedbfff10ddf7f6883b61e4631b8dc2c5adfad:0",
                        "confirmations": 0
                },
                {
                        "address_type": 4,
                        "address": "bc1py45gpxlexcdvwgne7cmfh8zngd6llqpede02zjwmkdu6fmd8x3vqjd0p72",
                        "amount_sat": 2052362,
                        "pk_script": "51202568809bf9361ac72279f6369b9c534375ff80396e5ea149dbb379a4eda73458",
                        "outpoint": "1e345ec40d3a02ddef1112f9425599e51e72269255f3185effcc05a91261f33a:0",
                        "confirmations": 0
                }
        ]

When I query the transaction from listchaintxns I get the raw tx.  When I broadcast, I get no error from lnd, but on external site I get this error:
"Code: -26, Error: insufficient fee, rejecting replacement 53085820a65121739be6ffb067aedbfff10ddf7f6883b61e4631b8dc2c5adfad, less fees than conflicting txs; 0.00000183 < 0.00000194"
Digging deeper, I find that the first input is a lightning anchor, and has been swept already.  https://mempool.space/address/bc1qrh433dns65em58nrxc3jmqz80zfjphccawn74xr60feuna8m8wvsdw2j60
It seems that this address is collecting and sweeping lots of lightning anchors.  https://mempool.space/address/bc1ptztt50y5xk2pngsf8kfjd5qvek7qg485ks6nj8aq9p2k25mgqrwsy8rsar
So maybe this is not detected by LND, and it's broadcasting a transaction with invalid input?  I mean, these are all 330 sat invoices, but this address has collected a ton of these.  What's going on?

likely related to https://github.com/lightningnetwork/lnd/issues/6241

Ok, the node keeps trying to sweep these already spent utxos, and it's locking up my actual utxos in transactions that will never be confirmed.

Also likley related to
https://github.com/lightningnetwork/lnd/discussions/7420

So I recently decided to see if it's related to me running lnd in neutrino mode. I've setup a bitcoind node and connected to it with the --reset-wallet-transactions arg. After the sync we have:
$ lncli walletbalance
{
    "total_balance":  "6389436",
    "confirmed_balance":  "6389436",
    "unconfirmed_balance":  "0",
    "locked_balance":  "0",
    "reserved_balance_anchor_chan":  "0",
    "account_balance":  {
        "default":  {
            "confirmed_balance":  "6389436",
            "unconfirmed_balance":  "0"
        }
    }
}

I should have around 14000000 so we're missing around 8000000.  So looking at my closed channels I noticed there are 3 that's not claimed:
$ lncli closedchannels | jq .[].[].resolutions[].outcome | uniq -c
      3 "UNCLAIMED"
     12 "CLAIMED"

Perhaps the unclaimed channels are the ones I still have funds in?  Here's the info from the unclaimed channels:
$ lncli closedchannels | jq '[.[][] | select(.resolutions[].outcome == "UNCLAIMED")]'
[
  {
    "channel_point": "a725b1c0d8d352798209f4d835c888992f0ebafef7bb13bce35e183938dc0797:1",
    "chan_id": "810590758345900033",
    "chain_hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
    "closing_tx_hash": "110ce39c72b251eef89205f1f45d50aa57a1925dc0b4f0ca02f34fe7ee1067c5",
    "remote_pubkey": "03c436af41160a355fc1ed230a64f6a64bcbd2ae50f12171d1318f9782602be601",
    "capacity": "500000",
    "close_height": 799924,
    "settled_balance": "11342",
    "time_locked_balance": "0",
    "close_type": "REMOTE_FORCE_CLOSE",
    "open_initiator": "INITIATOR_REMOTE",
    "close_initiator": "INITIATOR_REMOTE",
    "resolutions": [
      {
        "resolution_type": "COMMIT",
        "outcome": "UNCLAIMED",
        "outpoint": {
          "txid_bytes": "c56710eee74ff302caf0b4c05d92a157aa505df4f10592f8ee51b2729ce30c11",
          "txid_str": "110ce39c72b251eef89205f1f45d50aa57a1925dc0b4f0ca02f34fe7ee1067c5",
          "output_index": 2
        },
        "amount_sat": "11342",
        "sweep_txid": "6568674c1b86fd0481075c3bf2f47801acd378ffdeca915299f8d275976ed452"
      }
    ],
    "alias_scids": [],
    "zero_conf_confirmed_scid": "0"
  },
  {
    "channel_point": "d7e9191a3d01e796be85da28cfa2962207518e10a9af79bbdf42608eeaf549c2:1",
    "chan_id": "810587459901456385",
    "chain_hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
    "closing_tx_hash": "222b5b369258d0c5e98de02a894021fe1048fc14dbc19ff8023255fdd05b58fd",
    "remote_pubkey": "03c436af41160a355fc1ed230a64f6a64bcbd2ae50f12171d1318f9782602be601",
    "capacity": "1500000",
    "close_height": 799924,
    "settled_balance": "56484",
    "time_locked_balance": "0",
    "close_type": "REMOTE_FORCE_CLOSE",
    "open_initiator": "INITIATOR_LOCAL",
    "close_initiator": "INITIATOR_REMOTE",
    "resolutions": [
      {
        "resolution_type": "COMMIT",
        "outcome": "UNCLAIMED",
        "outpoint": {
          "txid_bytes": "fd585bd0fd553202f89fc1db14fc4810fe2140892ae08de9c5d05892365b2b22",
          "txid_str": "222b5b369258d0c5e98de02a894021fe1048fc14dbc19ff8023255fdd05b58fd",
          "output_index": 2
        },
        "amount_sat": "56484",
        "sweep_txid": "6568674c1b86fd0481075c3bf2f47801acd378ffdeca915299f8d275976ed452"
      }
    ],
    "alias_scids": [],
    "zero_conf_confirmed_scid": "0"
  },
  {
    "channel_point": "7963009b05c981f8176bf4a58bf24096d9a5ded3f7a88a0246a797756bfb9a0e:1",
    "chan_id": "830501814529359873",
    "chain_hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
    "closing_tx_hash": "1dea1cd6ad6e44a15bf3e13ccd1939cf4f4dac9f66a3c523ded7a466fc3d1d37",
    "remote_pubkey": "0298f6074a454a1f5345cb2a7c6f9fce206cd0bf675d177cdbf0ca7508dd28852f",
    "capacity": "5000000",
    "close_height": 811573,
    "settled_balance": "0",
    "time_locked_balance": "0",
    "close_type": "LOCAL_FORCE_CLOSE",
    "open_initiator": "INITIATOR_REMOTE",
    "close_initiator": "INITIATOR_LOCAL",
    "resolutions": [
      {
        "resolution_type": "COMMIT",
        "outcome": "UNCLAIMED",
        "outpoint": {
          "txid_bytes": "371d3dfc66a4d7de23c5a3669fac4d4fcf3919cd3ce1f35ba1446eadd61cea1d",
          "txid_str": "1dea1cd6ad6e44a15bf3e13ccd1939cf4f4dac9f66a3c523ded7a466fc3d1d37",
          "output_index": 4
        },
        "amount_sat": "3155497",
        "sweep_txid": "4125205d70d6cecbb2d934c86b5aaf75bc2a7155e3413809e2ded6b4b3a3853b"
      }
    ],
    "alias_scids": [],
    "zero_conf_confirmed_scid": "0"
  }
]

The sum of amount_sat only comes to 11342 + 56484 + 3155497 = 3223323 so definitely not all of it but it's something?
Other info:
$ lncli --version
lncli version 0.18.3-beta commit=v0.18.3-beta
$ lnd --version
lnd version 0.18.3-beta commit=v0.18.3-beta

LMK if you need any other info.

Thanks for the extra info @WalterSmuts  🙏 Lemme check if the sweeper-god has some insights here cc @yyforyongyu

also want to cc @saubyk  - feels like we should keep an eye on this as it didnt resolve itself & im sure by now all the timeouts have resolved

The current state,

For channel<PHONE_NUMBER>45900033, the to_local output has been swept in this tx.
For channel<PHONE_NUMBER>01456385, the to_local output has been swept in this tx.
For channel<PHONE_NUMBER>29359873, however, the to_local output was never swept, as shown here. This channel appears to be a non-anchor channel, as indicated by one of the outputs using V0_P2WPKH.

The unexpected behaviors are,

for case 1 and 2, these swept utxos should be shown under the balance.
for case 3, the output is not swept.

This might also be related to #8001 and #8786.
To further investigate this issue,

lncli wallet listsweeps --verbose to give us the pending sweeps
lncli listunspent to give us the wallet UTXOs.
restart the node with debug flag, and without the flag --reset-wallet-transactions, and share the debug logs.

So I got the outputs of the above commands and uploaded them. I'm also running my LND node with debug logging per default, so I just did a stop start (without --reset-wallet-transactions) unlocked my wallet and zipped up my entire log directory after waiting a minute or two for the dust to settle.
lnd-logs.tar.gz
list-sweeps.txt
unspent.txt

More findings from the cli results,

For channel<PHONE_NUMBER>45900033 and<PHONE_NUMBER>01456385, the outputs were aggregated and swept in this tx, and is properly shown under listunspent as outpoint: 6568674c1b86fd0481075c3bf2f47801acd378ffdeca915299f8d275976ed452:0.

For channel<PHONE_NUMBER>29359873, the output was swept in this tx and is properly shown under listunspent as outpoint: 4125205d70d6cecbb2d934c86b5aaf75bc2a7155e3413809e2ded6b4b3a3853b:0`

So I think the closechannels has a bug that shows resolved outputs as unclaimed.

I should have around 14000000 so we're missing around 8000000.

@WalterSmuts Do you recall when was the last time you saw this balance? Meanwhile, could you do the followings,

restart the node with the flag --reset-wallet-transactions, and share the debug logs.
run lncli wallet pendingsweeps

@WalterSmuts Do you recall when was the last time you saw this balance? Meanwhile, could you do the followings,

A couple of months before this issue was created. I'd guess around June/July 2022.

Meanwhile, could you do the followings,

restart the node with the flag --reset-wallet-transactions, and share the debug logs.

The previous logs I've uploaded should have the same. Will do this again although AFAIK the sync takes a while.

run lncli wallet pendingsweeps

Right now (before restarting with --reset-wallet-transactions again) I get:
$ lncli wallet pendingsweeps
{
	"pending_sweeps": []
}

Did a quick debugging session with @Roasbeef yesterday, and think the closechannels was giving misleading info due to a previous version of the sweeper. Since the sweeping tx was published first then saved to db, it could be the case that it was published, then the node shut down, and the tx was not stored. When we came back up, the node would republish again, causing the sweeper to think the already published tx wasn't ours, hence saying it's unclaimed. This is no longer an issue now as the new sweeper will always fetch the mempool before attempting another broadcast.
As for the missing balance, we are still investigating, and would be helpful to have some debug logs🙏

Rescan finished:
$ zgrep "LNWL: Finished rescan for" .lnd/logs/bitcoin/mainnet/*
.lnd/logs/bitcoin/mainnet/lnd.log.6787.gz:2024-11-19 12:27:26.452 [INF] LNWL: Finished rescan for 301 addresses (synced to block<PHONE_NUMBER>0000000001446bb53eba6ebddb6b9784a5fd7c15b3b83e6f4c2372, height 871031)

Uploaded the entire log directory
Uploading lnd-logs.tar.gz…

@yyforyongyu Any luck with the logs?

@WalterSmuts too bad nope :( But I did find a reproducible failure from our recent itest PRs, will investigate!


Allow for standard range notation

The notation X/Y is normally viewed as X-(MAX)/Y. This patch employs
that functionality.
For example
15/30 for minutes should fire at both 15 and 45 minutes past the hour.

@wishdev Hello, thanks for this patch.
I looked at man 5 crontab on my dev machine (OpenBSD) and on Linux, it doesn't specify anything. By "Standard", what do you mean?
Thanks in advance, it will help me documenting your patch.

My apologies on the use of the word standard here - I apparently misspoke slightly.
The quartz scheduler [1] is a cron tool I've used in the past and while I knew it was different because it accepted seconds - I was unaware it also was different in using this notation.
So for crontab.5 it appears that, as an example, 15/30 for minutes, is an invalid notation. For quartz 15/30 works as the patch does.
Fugit, prior this patch, sort of sat in the middle and would interpret 15/30 as 15 minutes after the hour - so I guess the 2 options are to extend out, as the patch does, to allow this form of notation - or to revert it all the way back and make 15/30 invalid.
Sorry for my misunderstanding as to the lay of the land. I got directly stuck in the middle on this one
[1] - http://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html

Hello, no worries. Thanks a ton for taking the time to answer.
I think I will release as 1.5.0 since it introduces a behaviour change.
Thanks again!


Cors errors with v1.0.1

I've switched over from tuupola/slim-jwt-auth to JimTools/jwt-auth v1.0.1 which should be a straight swap, if I'm not mistaken. But my locahost web app shows CORS errors.
I don't really have any more details to share. All I have done is replace "tuupola/slim-jwt-auth": "3.8.0" with "jimtools/jwt-auth": "1.0.1" in my composer.json file and then ran composer update
Is there any further details that I can share that will help?

Checked over my code. The issue was with my code and my JWT decode it worked fine with JWT v5. Rewrote my code. All good now.


files under integration tests doesn't seem to trigger CI correctly.

   - uses: dorny/paths-filter@v2
        id: filter
        with:
          filters: |
            crates/youki: crates/youki/**
            crates/libcontainer: crates/libcontainer/**
            crates/libcgroups: crates/libcgroups/**

            tests/rust-integration-tests/runtimetest: ./tests/rust-integration-tests/runtimetest
            tests/rust-integration-tests/integration_test: ./tests/rust-integration-tests/integration_test
            tests/rust-integration-tests/test_framework: ./tests/rust-integration-tests/test_framework

The highlight part looks incorrect. Requires more investigation.

/assign

Looks like there is something wrong with the rules, I can fix it.
https://github.com/marketplace/actions/paths-changes-filter
jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: dorny/paths-filter@v2
      id: filter
      with:
        filters: |
          backend:
            - 'backend/**'
          frontend:
            - 'frontend/**'

    # run only if 'backend' files were changed
    - name: backend tests
      if: steps.filter.outputs.backend == 'true'
      run: ...

    # run only if 'frontend' files were changed
    - name: frontend tests
      if: steps.filter.outputs.frontend == 'true'
      run: ...

    # run if 'backend' or 'frontend' files were changed
    - name: e2e tests
      if: steps.filter.outputs.backend == 'true' || steps.filter.outputs.frontend == 'true'
      run: ...