Ruby LSP attempts to index ~/Library when being run with BBEdit

Description
Reproduction steps

Start the Ruby LSP using BBEdit 15.1.x on MacOS Sonoma (14.x) with ruby language configured to use ~/.asdf/shims/ruby-lsp with and without the default stdio argument.
Tail the bbedit lsp log (/Users//Library/Containers/com.barebones.bbedit/Data/Library/Logs/BBEdit/LanguageServerProtocol-Ruby.txt)
Open a project window from the root of project (in this case a rails app). (bbedit . works well for this from a terminal window)
LSP fails to index see log at bottom of this summary (I substituted some project/username dirs with <username>, <sub-folder> etc to be conscientious about it being a work project.)

My apologies if non-vs-code use isn't fully supported yet. The BBEdit devs have been fairly responsive to my requests for help troubleshooting on their end and made some changes to try to keep the ruby-lsp server focused on the current workspace, but are really unsure as to why this is happening. I started a conversation in the Ruby DX slack with some good suggested troubleshooting ideas, but it got lost to history before I had time to revisit this issue.
================================================================================
2024-07-24 21:06:49.356: Application startup: 15.1.2 (15B37)
2024-07-24 21:06:49.356: macOS version 14.5 (23F79)
2024-07-24 21:06:49.356: Using guessed workspace context: file:///Users/<username>/dev/<sub-folder>/<project-folder>/
2024-07-24 21:06:49.356: Initialization parameters sent to server: {
    capabilities =     {
        textDocument =         {
            codeAction =             {
                codeActionLiteralSupport =                 {
                    codeActionKind =                     {
                        valueSet =                         (
                            info,
                            quickfix,
                            refactor,
                            source
                        );
                    };
                };
            };
            completion =             {
                completionItem =                 {
                    deprecatedSupport = 1;
                    documentationFormat =                     (
                        markdown,
                        plaintext
                    );
                    insertReplaceSupport = 1;
                    insertTextModeSupport =                     {
                        valueSet =                         (
                            1,
                            2
                        );
                    };
                    preselectSupport = 1;
                    snippetSupport = 1;
                };
            };
            documentSymbol =             {
                hierarchicalDocumentSymbolSupport = 1;
                labelSupport = 1;
            };
            hover =             {
                contentFormat =                 (
                    markdown,
                    plaintext
                );
            };
            onTypeFormatting =             {
            };
            publishDiagnostics =             {
                categorySupport = 1;
                codeActionsInline = 1;
                codeDescription = 1;
                dataSupport = 1;
                relatedInformation = 1;
            };
            rename =             {
                prepareSupport = 1;
                prepareSupportDefaultBehavior = 1;
            };
            signatureHelp =             {
                signatureInformation =                 {
                    activeParameterSupport = 1;
                    documentationFormat =                     (
                        markdown,
                        plaintext
                    );
                    parameterInformation =                     {
                        labelOffsetSupport = 1;
                    };
                };
            };
            synchronization =             {
                didSave = 1;
                willSave = 1;
            };
        };
        workspace =         {
            applyEdit = 1;
            configuration = 1;
            workspaceEdit =             {
                documentChanges = 0;
                failureHandling = abort;
            };
            workspaceFolders = 1;
        };
    };
    clientInfo =     {
        name = BBEdit;
        version = "15.1.2";
    };
    initializationOptions =     {
        diagnostics = 1;
    };
    rootUri = "file:///Users/<username>/dev/<sub-folder>/<project-folder>/";
    trace = verbose;
    workspaceFolders =     (
                {
            name = "<project-folder>";
            uri = "file:///Users/<username>/dev/<sub-folder>/<project-folder>/";
        }
    );
}
2024-07-24 21:06:49.356: Starting server, command: ruby-lsp, arguments: (
)
2024-07-24 21:06:49.356: Waiting for server startup to complete...
2024-07-24 21:06:49.687: stderr output from server: Ruby LSP> Skipping lockfile copies because there's no top level bundle

2024-07-24 21:06:49.703: stderr output from server: Ruby LSP> Running bundle install for the custom bundle. This may take a while...
Ruby LSP> Command: (bundle check || bundle install) 1>&2

2024-07-24 21:06:49.818: stderr output from server: The Gemfile's dependencies are satisfied

2024-07-24 21:06:50.133: stderr output from server: Initializing Ruby LSP v0.17.9...

2024-07-24 21:06:50.147: server startup response: {
    capabilities =     {
        codeActionProvider =         {
            resolveProvider = 1;
        };
        codeLensProvider =         {
        };
        completionProvider =         {
            completionItem =             {
                labelDetailsSupport = 1;
            };
            resolveProvider = 1;
            triggerCharacters =             (
                "/",
                "\"",
                "'",
                ":",
                "@",
                "."
            );
        };
        definitionProvider = 1;
        diagnosticProvider =         {
            interFileDependencies = 0;
            workspaceDiagnostics = 0;
        };
        documentHighlightProvider = 1;
        documentLinkProvider =         {
        };
        documentOnTypeFormattingProvider =         {
            firstTriggerCharacter = "{";
            moreTriggerCharacter =             (
                "\n",
                "|",
                d
            );
        };
        documentSymbolProvider =         {
            hierarchicalDocumentSymbolSupport = 1;
            symbolKind =             {
                "value_set" =                 (
                    1,
                    2,
                    3,
                    4,
                    5,
                    6,
                    7,
                    8,
                    9,
                    10,
                    11,
                    12,
                    13,
                    14,
                    15,
                    16,
                    17,
                    18,
                    19,
                    20,
                    21,
                    22,
                    23,
                    24,
                    25,
                    26
                );
            };
        };
        experimental =         {
            "addon_detection" = 1;
        };
        foldingRangeProvider =         {
            lineFoldingOnly = 1;
        };
        hoverProvider =         {
        };
        inlayHintProvider =         {
        };
        positionEncoding = "utf-16";
        selectionRangeProvider = 1;
        semanticTokensProvider =         {
            documentSelector =             (
                                {
                    language = ruby;
                }
            );
            full =             {
                delta = 0;
            };
            legend =             {
                tokenModifiers =                 (
                    declaration,
                    definition,
                    readonly,
                    static,
                    deprecated,
                    abstract,
                    async,
                    modification,
                    documentation,
                    "default_library"
                );
                tokenTypes =                 (
                    namespace,
                    type,
                    class,
                    enum,
                    interface,
                    struct,
                    typeParameter,
                    parameter,
                    variable,
                    property,
                    enumMember,
                    event,
                    function,
                    method,
                    macro,
                    keyword,
                    modifier,
                    comment,
                    string,
                    number,
                    regexp,
                    operator,
                    decorator
                );
            };
            range = 1;
        };
        signatureHelpProvider =         {
            triggerCharacters =             (
                "(",
                " ",
                ","
            );
        };
        textDocumentSync =         {
            change = 2;
            openClose = 1;
        };
        typeHierarchyProvider =         {
        };
        workspaceSymbolProvider = 1;
    };
    formatter = none;
    serverInfo =     {
        name = "Ruby LSP";
        version = "0.17.9";
    };
}
2024-07-24 21:06:50.147: ...completed server startup.
2024-07-24 21:06:50.148: stderr output from server: Finished initializing Ruby LSP!

2024-07-24 21:06:50.722: Server message (error): Error while indexing: Operation not permitted - /Users/<username>/Library/Application Support/com.apple.LaunchServicesTemplateApp.dv

The only paths we try to index automatically are gem installation paths and the files inside the workspace.
If you run this
gem env path

Do any of the entries include anything under ~/Library? Do you happen to have an .index.yml or other Ruby LSP indexing configuration? Any possible symlinks pointing to ~/Library?
We rely on Bundler for figuring out all of the paths we're going to index, so it might be worth checking Bundler configuration too.

@andyw8
I can run ruby-lsp --doctor and it only indexes my local gems and my project files...
Same with running the command inside a BBEdit Shell Worksheet
I wonder if there's something in the config BBEdit is passing in:
2024-07-24 21:06:49.356: Initialization parameters sent to server: {
    capabilities =     {
        textDocument =         {
            codeAction =             {
                codeActionLiteralSupport =                 {
                    codeActionKind =                     {
                        valueSet =                         (
                            info,
                            quickfix,
                            refactor,
                            source
                        );
                    };
                };
            };
            completion =             {
                completionItem =                 {
                    deprecatedSupport = 1;
                    documentationFormat =                     (
                        markdown,
                        plaintext
                    );
                    insertReplaceSupport = 1;
                    insertTextModeSupport =                     {
                        valueSet =                         (
                            1,
                            2
                        );
                    };
                    preselectSupport = 1;
                    snippetSupport = 1;
                };
            };
            documentSymbol =             {
                hierarchicalDocumentSymbolSupport = 1;
                labelSupport = 1;
            };
            hover =             {
                contentFormat =                 (
                    markdown,
                    plaintext
                );
            };
            onTypeFormatting =             {
            };
            publishDiagnostics =             {
                categorySupport = 1;
                codeActionsInline = 1;
                codeDescription = 1;
                dataSupport = 1;
                relatedInformation = 1;
            };
            rename =             {
                prepareSupport = 1;
                prepareSupportDefaultBehavior = 1;
            };
            signatureHelp =             {
                signatureInformation =                 {
                    activeParameterSupport = 1;
                    documentationFormat =                     (
                        markdown,
                        plaintext
                    );
                    parameterInformation =                     {
                        labelOffsetSupport = 1;
                    };
                };
            };
            synchronization =             {
                didSave = 1;
                willSave = 1;
            };
        };
        workspace =         {
            applyEdit = 1;
            configuration = 1;
            workspaceEdit =             {
                documentChanges = 0;
                failureHandling = abort;
            };
            workspaceFolders = 1;
        };
    };
    clientInfo =     {
        name = BBEdit;
        version = "15.1.2";
    };
    initializationOptions =     {
        diagnostics = 1;
    };
    rootUri = "file:///Users/<username>/dev/<sub-folder>/<project-folder>/";
    trace = verbose;
    workspaceFolders =     (
                {
            name = "<project-folder>";
            uri = "file:///Users/<username>/dev/<sub-folder>/<project-folder>/";
        }
    );
}

@vinistock interestingly
gem env path
/Users/<username>/.gem/ruby/2.6.0:/Library/Ruby/Gems/2.6.0:/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/gems/2.6.0

that's from in a BBEdit shell worksheet which I think would be the same env as bbedit tries to shell out to ruby-lsp

I wonder if BBEdit is running it with a current working directory of ~ and assuming the workspace setting will override it. Is there a flag I can pass to ruby-lsp to not auto-index the current working dir?

Not really, these are the indexing configurations we expose.
My suspicion is that this is related to some intersection of BBEdit and ASDF. Something might be overriding the GEM_HOME or GEM_PATH and we end up trying to index Library.

I was able to get solargraph (BBEdit's default configured ruby language server) working, but I don't know if it has the same GEM_HOME/GEM_PATH behavior, or what it does when it hits a permission error. I'm going to see if I can wrap the ruby-lsp binary in a shell script so I can echo those environment values. My zsh scripting skills are... minimal though, so we'll see how this goes.

@vinistock you called it inside BBEdit's shell worksheet running gem env
gem env
RubyGems Environment:
  - RUBYGEMS VERSION: <IP_ADDRESS>
  - RUBY VERSION: 2.6.10 (2022-04-12 patchlevel 210) [universal.arm64e-darwin23]
  - INSTALLATION DIRECTORY: /Library/Ruby/Gems/2.6.0
  - USER INSTALLATION DIRECTORY: /Users/drew/.gem/ruby/2.6.0
  - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
  - GIT EXECUTABLE: /usr/bin/git
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - SPEC CACHE DIRECTORY: /Users/drew/.gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: /Library/Ruby/Site
  - RUBYGEMS PLATFORMS:
    - ruby
    - universal-darwin-23
  - GEM PATHS:
     - /Library/Ruby/Gems/2.6.0
     - /Users/drew/.gem/ruby/2.6.0
     - /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/gems/2.6.0
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - https://rubygems.org/
  - SHELL PATH:
     - /usr/local/bin
     - /System/Cryptexes/App/usr/bin
     - /usr/bin
     - /bin
     - /usr/sbin
     - /sbin
     - /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin
     - /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin
     - /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin
     - /Users/drew/.asdf/shims
     - /Users/drew/.asdf/bin
     - /usr/local/sbin
     - /opt/homebrew/bin
     - /opt/homebrew/sbin

I'll figure out how to override it in .zshenv to something sane. Thanks for helping me run this to ground.

it's being set by /etc/profile
/usr/libexec/path_helper -s gets prepended to the path
which puts system ruby ahead of the one set by asdf in zshenv
BBEdit runs a non-interactive login shell so zshrc (which must come after /etc/profile) gets run and puts the asdf supplied ruby back in front.

@andyw8 I did a little more experimenting and even with the right env it still tries to index my home dir when started up from a non-interactive login shell (what BBEdit uses to run the language servers)
I made a test script (lang-serv.sh)
#! /bin/zsh
echo $PATH >&2
which ruby >&2
ruby --version >&2
gem env >&2
pwd
ruby-lsp

pwd prints no output but the first time it gets an index command from BBEdit it attempts to index my home dir
same thing happens if I add --doctor to my script.
if I add a line that cd's to my main project directory everything works fine and dandy.

Ok looking at https://github.com/Shopify/ruby-lsp/blob/main/lib/ruby_indexer/lib/ruby_indexer/configuration.rb#L27 it looks like ruby-lsp always attempts to index the Dir.pwd in addition to whatever workspace configs are passed in, but maybe I'm misreading this?


 IF YOU DO NOT FOLLOW THE FORMAT OR MAKE A GENERIC TOKEN REQUEST YOUR ISSUE WILL BE DELETED WITHOUT COMMENT
YOUR JUSTLIST MUST FOLLOW THE JSON SPECIFICATION
https://github.com/justswaporg/justlists/blob/main/example.justlists.ts
Checklist

[ ] I understand that this is not the place to request a token listing.
[ ] I have tested that my JustList is compatible by pasting the URL into the add a list UI at justswap.org.
[ ] I understand that filing an issue or adding liquidity does not guarantee addition to the justlists website.

Please provide the following information for your token.
JustList URL must be HTTPS.
JustList URL:
JustList Name:
Link to the official homepage of the JustList manager:

Sorry, your issue will be closed as you did not submit your information in the correct URL.Please resubmit.

Sorry, your issue will be closed as you did not submit your information in the correct format.Please resubmit.


Fix input location variable for the changes in monai WSI datasets

Description
This PR updates the pathology tumor detection bundle to fix the location input change to reflect the changes in monai wsi datasets.
Status
Ready
Please ensure all the checkboxes:

[x] Codeformat tests passed locally by running ./runtests.sh --codeformat.
[x] In-line docstrings updated.
[x] Update version and changelog in metadata.json.
[x] Ensure versions of packages such as monai, pytorch and numpy are correct in metadata.json.
[x] Descriptions should be consistent with the content, such as eval_metrics of the provided weights and TorchScript modules.
[x] Files larger than 25MB are excluded and replaced by providing download links in large_file.yml.
[x] Avoid using path that contains personal information within config files (such as use /home/your_name/ for "bundle_root").

/build


fix: enhancements to config parsing and dao

This PR introduces a number of enhancements:

Client ID max length is now enforced at the business logic layer using metric.Validate(). This allows us to respond with a proper message when the max length has been exceeded. Ping @psturc.
the dao package now has some small amount of retry logic which will let the server retry connecting to the db for up to 5 seconds before failing. This solves a minor issue particularly in docker-compose where the server sometimes starts before the database is ready to accept connections. Ping @josemigallas.
Configuration parsing has been hardened and refactored. All connection options supported by the postgres driver are now supported and the connection string can be dynamically generated based off what config/env vars are present. This means we won't need to do any refactoring of the DB connection in the future.
The dao package now calls db.SetMaxOpenConns() with a default of 100 which is apparently the default allowed by Postgres. See docs.

Verification
Delete all containers previously run by docker-compose. You can get the container IDs with the following docker ps -a | grep aerogearappmetrics
Then run docker rm <id> for each id.
Then forcefully recreate your docker-compose environment with the following:
docker-compose up --build --force-recreate

You should notice 2 things:

The metrics server did not crash while trying to connect to the database.

Make the following curl request:

curl -X POST \
  http://localhost:3000/metrics \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -H 'Postman-Token: 7011091f-b785-2c89-bfe8-55383df253f9' \
  -d '{
  "clientId": "453de743211112345678900987654312345678908776423567890876543678907654356789076543536789765436789076543256789076543256789654321456789654321456789765432567869765432567896543256789765432145678976543214567897654324567896543214567897654321245678976543256789765432145678965432567896543256786543214567865432",
  "data": {
    "app": {
      "id": "com.example.someApp",
      "sdkVersion": "2.4.6",
      "appVersion": "256"
    },
    "device": {
      "platform": "android",
      "platformVersion": "27"
    }
  }
}'

And you should see the following message:
{
    "error": "Bad Request",
    "message": "clientId exceeded maximum length of 128",
    "statusCode": 400
}

@darahayes I couldn't verify according to the steps provided.
I'm getting error when running the docker-compose command:
Step 4/5 : COPY ${BINARY} /opt/aerogear-app-metrics
ERROR: Service 'api' failed to build: COPY failed: stat /var/lib/docker/tmp/docker-builder721829778/dist/linux_amd64/aerogear-app-metrics: no such file or directory

My bad @psturc you must run make build_linux before running docker-compose

I'm not sure what I'm doing wrong - make build or make build_linux does not work for me.
However it's working fine in master branch.

@psturc This is strange. It seems to me by the error message that you do not have the latest code. It's building on my machine and in CircleCI.

No unchanged relevant lines lost coverage.
Overall coverage increased (+2.3%) to 88.732%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/dao/db.go
10
12
83.33%

Totals

Change from base Build #5:
2.3%

Covered Lines:
189

Relevant Lines:
213

💛  - Coveralls

@psturc I've merged master back into this branch can you try pulling again? If that doesn't work can you try deleting and fetching the branch again? Or perhaps cloning the repo again? I'm out of ideas beyond this 😅

@darahayes code lgtm, the clientId validation is fine, I think limit for 128 chars should be sufficient.
However I cannot verify this locally, I tried everything you've suggested above, but the build is still failing with the same error.
Could anybody else please try that too?

@psturc I think I figured out your issue: in the logs you sent me I saw the path ~/gocode/src/github.com/aerogear/aerogear-metrics-api
Please ensure you have the latest code cloned to the directory aerogear-app-metrics. I think your compiler is pulling in old code from a different directory

@darahayes lol of course, nice catch Dara :) I will verify it locally soon then

@darahayes I just noticed one thing, unfortunately unrelated to this PR.
There's a difference between API and client side in one property (appId vs id):
Android & iOS vs. metrics-api
I think appId property is more clear - so maybe we would need a change on metrics-api side, wdyt?

@psturc Great catch. Let's update the server and the original proposal.

@psturc I've updated the id property as suggested.

Ok, verified that appId chage

@psturc Did you manage to verify the other steps?

@darahayes yes, sorry I forgot to mention that it was all verified with iOS client


Add ability to delete layers and voxels from account

Added functionality here. Still need to add error messages.


I can't use last version of permission_handler

Hi again @vavadiyahiren  @dr7866 ,
Situation 1: When i delete proguard rules the problem doesn't occurs but the app doesn't work for release version.
Situation 2: When i use flutter_plugin 2.2.3 and permission_handler 9.2.0 the release version works but 9.2.0 version is not useful.
When it is debug mode everthing is fine but i can't get release verison. I have tried many solutions but none of them work.
Problem: When i use permission_handler above version 9.2.0 with flutter_plugin i have error given below:
of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: C:/Users/Mehmet/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.8.22/636bf8b320e7627482771bbac9ed7246773c02bd/kotlin-stdlib-1.8.22.jar!/META-INF/kotlin-stdlib-jdk7.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: C:/Users/Mehmet/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.8.22/636bf8b320e7627482771bbac9ed7246773c02bd/kotlin-stdlib-1.8.22.jar!/META-INF/kotlin-stdlib.kotlin_module: Module
was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: C:/Users/Mehmet/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.8.22/636bf8b320e7627482771bbac9ed7246773c02bd/kotlin-stdlib-1.8.22.jar!/META-INF/kotlin-stdlib-jdk8.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: C:/Users/Mehmet/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-common/1.8.22/1a8e3601703ae14bb58757ea6b2d8e8e5935a586/kotlin-stdlib-common-1.8.22.jar!/META-INF/kotlin-stdlib-common.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
ERROR:C:\Users\Mehmet\.gradle\caches\transforms-3\ce540d9ec80933075f329cb7f379f5b3\transformed\jetified-bcprov-jdk15on-1.65.jar: R8: Type org.bouncycastle.jcajce.provider.asymmetric.edec.KeyFactorySpi$Ed25519 is defined multiple times: C:\Users\Mehmet\.gradle\caches\transforms-3\ce540d9ec80933075f329cb7f379f5b3\transformed\jetified-bcprov-jdk15on-1.65.jar:META-INF/versions/11/org/bouncycastle/jcajce/provider/asymmetric/edec/KeyFactorySpi$Ed25519.class, C:\Users\Mehmet\.gradle\caches\transforms-3\ce540d9ec80933075f329cb7f379f5b3\transformed\jetified-bcprov-jdk15on-1.65.jar:org/bouncycastle/jcajce/provider/asymmetric/edec/KeyFactorySpi$Ed25519.class

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:minifyReleaseWithR8'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.R8Task$R8Runnable
   > Compilation failed to complete, origin: C:\Users\Mehmet\.gradle\caches\transforms-3\ce540d9ec80933075f329cb7f379f5b3\transformed\jetified-bcprov-jdk15on-1.65.jar:META-INF/versions/11/org/bouncycastle/jcajce/provider/asymmetric/edec/KeyFactorySpi$Ed25519.class

> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BU�LD FAILED in 1m 55s
Running Gradle task 'assembleRelease'...                          116,1s

┌─ Flutter Fix ─────────────────────────────────────────────────────────────────────────────────────┐
│ [!] Your project requires a newer version of the Kotlin Gradle plugin.                            │
│ Find the latest version on https://kotlinlang.org/docs/releases.html#release-details, then update │
│ C:\Users\Mehmet\StudioProjects\tedis-2\android\build.gradle:                                      │
│ ext.kotlin_version = '<latest-version>'                                                           │
└───────────────────────────────────────────────────────────────────────────────────────────────────┘

android/build.gradle file:
buildscript {
    ext.kotlin_version = '1.7.10'
    repositories {
        google()
        mavenCentral()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:7.3.0'
        // START: FlutterFire Configuration
        classpath 'com.google.gms:google-services:4.3.10'
        // END: FlutterFire Configuration
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.buildDir = '../build'
subprojects {
    project.buildDir = "${rootProject.buildDir}/${project.name}"
}
subprojects {
    project.evaluationDependsOn(':app')
}

tasks.register("clean", Delete) {
    delete rootProject.buildDir
}

android/app/build.gradle file:
plugins {
    id "com.android.application"
    id "kotlin-android"
    id "dev.flutter.flutter-gradle-plugin"
}

def localProperties = new Properties()
def localPropertiesFile = rootProject.file('local.properties')
if (localPropertiesFile.exists()) {
    localPropertiesFile.withReader('UTF-8') { reader ->
        localProperties.load(reader)
    }
}

def flutterVersionCode = localProperties.getProperty('flutter.versionCode')
if (flutterVersionCode == null) {
    flutterVersionCode = '1'
}

def flutterVersionName = localProperties.getProperty('flutter.versionName')
if (flutterVersionName == null) {
    flutterVersionName = '1.0'
}

android {
    namespace "com.example.tedis"
    compileSdkVersion flutter.compileSdkVersion
    ndkVersion flutter.ndkVersion

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    kotlinOptions {
        jvmTarget = '1.8'
    }

    sourceSets {
        main.java.srcDirs += 'src/main/kotlin'
    }

    defaultConfig {
        // TODO: Specify your own unique Application ID (https://developer.android.com/studio/build/application-id.html).
        applicationId "com.example.tedis"
        // You can update the following values to match your application needs.
        // For more information, see: https://docs.flutter.dev/deployment/android#reviewing-the-gradle-build-configuration.
        minSdkVersion flutter.minSdkVersion
        targetSdkVersion flutter.targetSdkVersion
        versionCode flutterVersionCode.toInteger()
        versionName flutterVersionName
        multiDexEnabled true
    }

    buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.debug
            proguardFiles getDefaultProguardFile("proguard-android.txt"),
                    "proguard-rules.pro"
        }
    }
}

flutter {
    source '../..'
}

dependencies {
    implementation 'androidx.multidex:multidex:2.0.1'
}

proguard files:
-keep class org.jivesoftware.** { *; }
-keep class org.xmlpull.** { *; }
-keep class org.bouncycastle.jcajce.provider.** { *; }
-keep class org.xrstudio.** { *; }

@fadihere

@fadihere

I believe that this issue occurs because of android gradle sync. Follow these steps and let me know if it works for you.

set latest kotlin version
flutter clean
open android folder in Android Studio
click on the gradle sync
go back to project dictionary and flutter run

@fadihere

I believe that this issue occurs because of android gradle sync. Follow these steps and let me know if it works for you.

set latest kotlin version
flutter clean
open android folder in Android Studio
click on the gradle sync
go back to project dictionary and flutter run

I tried it but many other problems occurred. For example:
Could not create an instance of type com.android.build.api.variant.impl.LibraryVariantBuilderImpl.
I'm trying to fix. Thanks for the answer.

@mehmetgencdal please just downgrade your Permission handler package version

@mehmetgencdal please just downgrade your Permission handler package version

Unfortunately when i downgrade the version the permission handler doesn't work. It doesn't ask for any permission.
I tried to upgrade the gradle version but it always fails. Is there any way to create a project with the latest gradle version? Then i can move the codes? @dr7866 @fadihere


Surplus amount being extracted when repaying full debt using RepayAdapter

ParaSwapRepayAdapter is used to repay the debt of user. It offers the functionality to pay partial debt or full debt to the user. When the user wants to pay the full debt of the asset, it is not possible for the UI to determine the amount of debt the user will have when the transaction is mined due to rebasing nature of debt tokens. Due to this, the UI calls the ParaSwap API with extra amount.
ParaSwap team investigated the transactions and found out that:

UI query a BUY trade for a certain amount Y and ParaSwap API would give the quoted amount X
ParaSwap API will build the calldata based on buy(X, Y)
then onchain, ParaSwapRepayAdapter perform extract processing which lead to ending up with a new value Y'(this may be less than Y)
ParaSwapRepayAdapter call augustus with buy(X, Y')

The last step is where the troubles arise, because Y' < Y, then on executing the actual buy, ParaSwap router would pull out of the user an amount X' < X but as pass the expected amount as X, and this leads to a virtual positive slippage and this is where ParaSwap router would take surplus (buy paradigm: the lower amount user spend the better it’s)
Potential Solution

While there is no straight solution for the above issue, the impact of the issue can be reduced by ensuring that the difference between amount of debt to be paid(at the time of transaction execution) and the amount quoted for paraswap api is less than certain threshold.
Currently, UI assumes that the transaction mining happens within 60 minutes and queries the ParaSwap API with the predicted debt amount after 60 minutes which is too pessimistic assumption. This can be reduced to 30 minutes so that difference of amount is reduced.

@miguelmtzinf

The integration of these contracts in the UI must use an accurate estimation of the full balance of the user so there is little difference between the amount used for the ParaSwap API call and the ParaSwap Augustus swap. A note about this matter to the Security considerations section of the README was added.


Observability and IncompleteEvents

When events are resubmitted, their original tracing context is lost.
Keeping this information is specially relevant when events are externalized.
Any thoughts on persisting context on the DB and restoring it when the event is read? Maybe using nullable column(s) and extracting context via an optional Bean, configured by spring-modulith-observability when this module is added.

Does it really make sense to fully reestablish that context? Wouldn't those traces then look like an actual request having been performed?

I think it makes sense regarding event traceability. I will try to explain why with an example.
Given this scenario:

Service A receives a request with Trace ID ABC
As a part of that request, it publishes MyEvent via RabbitMQ.
Service B receives MyEvent and does whatever.
Service Creceives MyEvent and does whatever.

Considering happy-path execution, Trace ID ABC would enable you to trace up from the initial request to Service A, down to MyEvent reception and processing in Service B and Service C.
However, if anything goes wrong publishing MyEvent (e.g., RabbitMQ is down for a few seconds) and it is finally published when retried from the EventRepository, it will be published with another Trace ID, and we won't be able to trace it down to Service B and Service C.
However, persisting the context and restoring it when retrying the event would solve this issue.
(Note: to simplify the example I'm referring only to the Trace ID, but the same would apply to other Trace Context info).

We could use the concepts of linked spans. That means that the new resubmission could happen at any time so if we kept the same trace id we would pollute the trace view. However we could create a new trace id and link the old one to the resubmitted one. WDYT?


make create object non network

it's better to be non-network and better get the closest object from anywhere with onesync infinity

Thanks, do you have any source about this?


Error between 1.11.8 to 1.11.9

I am getting this error when I updated my library from 1.11.8 to 1.11.9. I am unsure why this error is happening and it is happening on several of my entities and wondering if you can help me.
Error:  DynamoDBToolboxError: Invalid attribute detected while formatting: 'entity'. Should be one of: ItemShort.

When I make the name inside my entity lowercase it then works but I am unsure why that is the issue
export const ItemShort = new Entity({
	name: "ItemShort",

	schema: schema({
		id: string().key(),
	}),

	table: itemTable(),
});

Full error listed bellow:
Error:  DynamoDBToolboxError: Invalid attribute detected while formatting: 'entity'. Should be one of: ItemShort
  path: 'entity',
  payload: {
    received: 'itemShort',
    expected: [ 'ItemShort' ],
    partitionKey: 'someID,
    sortKey: undefined
  }
}

Hi @kartikpatel95 and thanks for reaching out!
The error seems to be that some items in your data have itemSchort (lowercase i) instead of ItemShort (uppercase I) in their internal entity attributes.
v1.11.9 did introduce some changes in the EntityFormatter action but I do not see how it would cause this bug:

In case of an enum being present, the raw value was already checked in v1.11.8
The entity internal attribute does not have a transformer so should not be impacted

I run some test on my side and do not seem to run into any issue. I would search first for other reasons that would introduce itemShort in lowercase first: Maybe some manual data handling in the console?

Thanks @ThomasAribart for that, we have identified that in the dynamoDB and resolved that issue now thanks to you. We are now encountering another defect after upgrading and hoping you would be able to assist. On 1.11.8 We don't get this defect but on the upgrade to 1.119 we do.
Error:  DynamoDBToolboxError: Missing required attribute for formatting: 'entity'. Partition key: .ItemOne
  code: 'formatter.missingAttribute',
  path: 'entity',
  payload: { partitionKey: '.ItemOne', sortKey: undefined }
}

The items inside this table are saved manually and not using dynamoDB toolbox, would that be an issue?

Yes as it can lead to manual error as this other error seems to be 😅 Probably someone forgot to input: _et: ".ItemOne" in this item.

Hi @ThomasAribart, thanks for the quick replies on this one. We're currently in the process of migrating to using dynamodb toolbox, and up to this version we could read the old objects with it.
We don't anticipate having all objects migrated before this goes live. Is there any config we can use to get dynamodb-toolbox to still read the data even though there is no _et in these?

@gligorkot I think you can add middleware stacks to the document client to reintroduce the entity attribute manually!
You can also set entityAttrFilter to false in Table actions to disable the automatic FilterExpression on the entity attribute (so they still retrieve the items).

Hi @ThomasAribart, I tried to set it on the Table actions but it seems that its not allowed on the Table action as its not part of the props. Do you happen to have a example how I can apply the entityAttrFilter?

@kartikpatel95 You'll find documentation on the scan, query and deletePartition action docs:
const { Items } = await PokeTable.build(ScanCommand)
  .entities(PokemonEntity)
  .options({
    entityAttrFilter: false
  })
  .send()

@ThomasAribart entityAttrFilter: false seems to no longer throw the error but the end result is that the item is not included in the result
{
  Items: [],
  Count: 1,
  ScannedCount: 1,
  '$metadata': {
    httpStatusCode: 200,
    requestId: 'H1LA77VQNE1T4F4AMK7M0EHH7JVV4KQNSO5AEMVJF66Q9ASUAAJG',
    extendedRequestId: undefined,
    cfId: undefined,
    attempts: 1,
    totalRetryDelay: 0
  }
}


[Bug]: Unexpected behaviour of the sensor ADC to Diameter

What happened?
Sensor is flashed with infidel_release_ee.ino, board with host_ee_prog.ino. This is calibration over I2C.
I have drill bits of different sizes to calibrate with: 1.4, 1.5, 1.6, 1.7, 1.8, 1.9 mm [for my sensor, 2mm doesn't fit at all, 1.9mm doesn't even go all the way in, and 1mm doesn't move the lever].
I expect the normal behaviour of the sensor to be as coded in infidel_release_ee.ino, and indicated in the docs, as shown by orange curve on the graph -> ADC increases with decreasing diameter.
What actually happens with my readings (Command 6)  is the opposite (Blue curve). My ADC readings increase with diameter.

Of course this means bad behaviour of the interpolation function convert2dia in  infidel_release_ee.ino, so I get incorrect readings when you import the calibrated values in EEPROM starting from the biggest diameter to the smallest, because it includes if (dia_table[i][0] > in) ...        return (out);       break.
Another issue is that the ADC range is less wide than expected. The range of ADC values given in firmware.rst is [617,999] for drill bits from 1 to 2mm, for me they are spread out from 26 to 282 for drill bits 1.4 to 1.9mm. The resolution is about 2 (=500/256) values of ADC per micron, it's still ok but I'm wondering whether this shift towards lower ADC values, and slight reduction in range is normal. Probably not...
Any solutions?
To solve the incorrect readings, I simply flipped the calibration  table so that ADC are sorted in ascending order with the line index of the table.

This solved the problem and my readings seem accurate. However I am wondering if I am the only one getting this deviation from the docs or if this is something that should be corrected in the documentation.
Additional info
I got the unpopulated PCB from Aisler, not altering anything from the SMT files there. Also got the BOM from Kitspace without deviations.

I think what happened is that you either inserted the magnet in the wrong direction, or that you calibrated in the wrong order (starting with 1.4 instead of 1.9).
@drspangle what side of the magnet should be pointing towards the sensor? @CCMCAGP you can find this out if you look at the raw readings (host_ee_prog.ino should output them, between 0 and 255). If they are less than 128, that means the south side of the magnet is pointing to the sensor, 128 and higher is north.
I agree there should be clearer instructions and also some examples given in the docs.

I'm not actually sure if it even matters what side of the magnet is facing the sensor, but the polarity of the sensor itself definitely matters. That said, I think your hypothesis that the calibration ordering was wrong seems like a much more plausible one than mine now that I think about it.

Having the ADC values in ascending order definitely was the right thing to do, before that convert2dia shouldn't really have worked (only output the highest value). According to the default table in infidel_release_ee.ino, the diameter should get smaller with bigger readings, so I don't really know what's the case here.
@CCMCAGP do you have calipers to measure the filament yourself?

Today I'm going to try and remove the lever to put another one with an opposite magnet side. I think that it's being inserted wrongly is the most plausible option. Other thing is, I have a N45 magnet instead of a N35. I would assume that would make the sensor react "better" than worse but then again, I don't know.
I interpreted the instructions in the video as "it doesn't matter which of the 3 pins of the sensor goes where in the PCB, as long as you install the magnet such that the magnet polarity doesn't make the LED light up..." (with calibration.ino flashed on)
As for the diameters, yes I have a caliper, even a micrometer actually, so I'm able to measure the drill bits size accurately. But as I said, I couldn't follow the calibration procedure per say, because the 2mm and 1mm drill bits were either not fitting in or not triggering anything.

I don't know about the strength of the magnets but if you get a usable signal it should be fine. The orientation of the sensor does actually matter (+, -, O, in that order, wouldn't want to swap them). Again, if you get a signal, this should be fine. The missing calibration points for 1mm and 2mm don't matter as long as there are enough points to interpolate from. What I suspect is happening with the current calibration table, is that your readings are 'mirrored'. So for example for the reading of 800 it will show the correct diameter of 1659. From there if the reading decreases, the diameter should increase, since the magnet is further away from the sensor. But according to your table they actually increase. Can you try whether this mirrored behaviour is actually the case? If so, you might be able to just turn the 2nd column in the table upside down (the diameter mappings).