Groups are not syncing in a bungee network

Hi there,
First of all, I really appreciate you putting time into the plugin. Secondly, I wanted to report a bug and that bug has to do with syncing the groups/ranks and permissions across a bungee network using MySQL database as a DB method. Every time I will get the following error in the console and it will never sync. I have tried a lot of things to fix it and even tried to change the DB host but nothing worked until now and I'm getting frustrated because of it tbh. Oh btw even if I specified the server name, it won't recognize it or it will not assign the group in the selected server even if I have everything correctly set up in the config files like server names, MySQL DB method and SQL messaging system method. If you maybe have a solution that can help me, it will be much appreciated. I just want the groups and ranks to sync with all servers when someone gets a rank in the future.
[20:31:51] [luckperms-scheduler-worker-1/INFO]: [LuckPerms] [Messaging] Received update ping with id: 7b79d837-c3fe-4b72-a4c2-1ed6c92c2c0c [20:32:07] [User Authenticator #3/WARN]: [LuckPerms] LuckPerms already has data for player 'DarkProvider' - but this data is stored under a different UUID. [20:32:07] [User Authenticator #3/WARN]: [LuckPerms] 'DarkProvider' has previously used the unique ids [75234c82-b802-39e2-a35a-172159e00e0b] but is now connecting with '0156f7f5-4cd6-4a94-87a2-0ad1f376b076' [20:32:07] [User Authenticator #3/WARN]: [LuckPerms] The UUID the player is connecting with now is Mojang-assigned (type 4). This implies that one of the other servers in your network is not authenticating correctly. [20:32:07] [User Authenticator #3/WARN]: [LuckPerms] If you're using BungeeCord/Velocity, please ensure that IP-Forwarding is setup correctly on all of your backend servers! [20:32:07] [User Authenticator #3/WARN]: [LuckPerms] See here for more info: https://github.com/lucko/LuckPerms/wiki/Network-Installation#pre-setup [20:32:07] [User Authenticator #3/INFO]: UUID of player DarkProvider is 0156f7f5-4cd6-4a94-87a2-0ad1f376b076 [20:32:07] [Server thread/INFO]: [ChatControl 9.0.2-BETA] Player Join took 0.03 ms [20:32:07] [Server thread/INFO]: DarkProvider[/<IP_ADDRESS>:57191] logged in with entity id 261 at ([Lobby]-683.5, 45.0, 577.5) [20:32:10] [Server thread/INFO]: DarkProvider issued server command: /lp listgroups [20:32:10] [Server thread/INFO]: lp [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up. [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at java.lang.reflect.Constructor.newInstance(Constructor.java:423) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.Util.getInstance(Util.java:408) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:919) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:898) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:887) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:861) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.ConnectionImpl.connectWithRetries(ConnectionImpl.java:2095) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2020) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:768) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:47) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at java.lang.reflect.Constructor.newInstance(Constructor.java:423) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:385) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:323) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.jdbc2.optional.MysqlDataSource.getConnection(MysqlDataSource.java:428) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.jdbc2.optional.MysqlDataSource.getConnection(MysqlDataSource.java:136) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at com.mysql.jdbc.jdbc2.optional.MysqlDataSource.getConnection(MysqlDataSource.java:107) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at simplepets.brainsynder.player.OwnerFile.lambda$reload$1(OwnerFile.java:170) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1632) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692) [20:32:12] [ForkJoinPool.commonPool-worker-15/WARN]: 	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)

That's what I'm always getting in the console when I excute a luckperms-related command in the server

This is the config file of one of the servers (It's a factions server)
`####################################################################################################
+----------------------------------------------------------------------------------------------+
|                                   __         __   ___  __         __                         |
|                        |    |  | /   |__/  |__) |__  |__)  |\/| /__                        |
|                        |___ _/ _, |  \  |    |___ |  \  |  | .__/                        |
|                                                                                |
|                                     https://luckperms.net                                    |
|                                                                                |
|  SOURCE CODE: https://github.com/lucko/LuckPerms                                             |
|  WIKI:        https://github.com/lucko/LuckPerms/wiki                                        |
|  BUG REPORTS: https://github.com/lucko/LuckPerms/issues                                      |
|                                                                                |
|  Each option in this file is documented and explained here:                                  |
|   ==>  https://github.com/lucko/LuckPerms/wiki/Configuration                                 |
|                                                                                |
|  New options are not added to this file automatically. Default values are used if an         |
|  option cannot be found. The latest config versions can be obtained at the link above.       |
+----------------------------------------------------------------------------------------------+
####################################################################################################
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                                      ESSENTIAL SETTINGS                                      |
|                                                                                |
|                   Important settings that control how LuckPerms functions.                   |
|                                                                                |
+----------------------------------------------------------------------------------------------+
The name of the server, used for server specific permissions.

- When set to "global" this setting is effectively ignored.
- In all other cases, the value here is added to all players in a "server" context.
- See: https://github.com/lucko/LuckPerms/wiki/Context
server: factions
If the servers own UUID cache/lookup facility should be used when there is no record for a player
already in LuckPerms.

- When this is set to 'false', commands using a player's username will not work unless the player
has joined since LuckPerms was first installed.
- To get around this, you can use a player's uuid directly in the command, or enable this option.
- When this is set to 'true', the server facility is used. This may use a number of methods,
including checking the servers local cache, or making a request to the Mojang API.
use-server-uuid-cache: false
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                                       STORAGE SETTINGS                                       |
|                                                                                |
|                Controls which storage method LuckPerms will use to store data.               |
|                                                                                |
+----------------------------------------------------------------------------------------------+
How the plugin should store data

- The various options are explained in more detail on the wiki:
https://github.com/lucko/LuckPerms/wiki/Storage-types

- Possible options:

|  Remote databases - require connection information to be configured below
|=> MySQL
|=> MariaDB (preferred over MySQL)
|=> PostgreSQL
|=> MongoDB

|  Flatfile/local database - don't require any extra configuration
|=> H2 (preferred over SQLite)
|=> SQLite

|  Readable & editable text files - don't require any extra configuration
|=> YAML (.yml files)
|=> JSON (.json files)
|=> HOCON (.conf files)
|=> TOML (.toml files)
|
| By default, user, group and track data is separated into different files. Data can be combined
| and all stored in the same file by switching to a combined storage variant.
| Just add '-combined' to the end of the storage-method, e.g. 'yaml-combined'

- A H2 database is the default option.
- If you want to edit data manually in "traditional" storage files, we suggest using YAML.
storage-method: MySQL
The following block defines the settings for remote database storage methods.

- You don't need to touch any of the settings here if you're using a local storage method!
- The connection detail options are shared between all remote storage types.
data:
Define the address and port for the database.
- The standard DB engine port is used by default
(MySQL: 3306, PostgreSQL: 5432, MongoDB: 27017)
- Specify as "host:port" if differs
address: <IP_ADDRESS>
The name of the database to store LuckPerms data in.
- This must be created already. Don't worry about this setting if you're using MongoDB.
database: xbitnetw_Luckyperms
Credentials for the database.
username: xbitnetw_estelthebest
password: 'Vj4m$#3k64G*Rpfv'
These settings apply to the MySQL connection pool.
- The default values will be suitable for the majority of users.
- Do not change these settings unless you know what you're doing!
pool-settings:
# Sets the maximum size of the MySQL connection pool.
# - Basically this value will determine the maximum number of actual
#   connections to the database backend.
# - More information about determining the size of connection pools can be found here:
#   https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
maximum-pool-size: 10

# Sets the minimum number of idle connections that the pool will try to maintain.
# - For maximum performance and responsiveness to spike demands, it is recommended to not set
#   this value and instead allow the pool to act as a fixed size connection pool.
#   (set this value to the same as 'maximum-pool-size')
minimum-idle: 10

# This setting controls the maximum lifetime of a connection in the pool in milliseconds.
# - The value should be at least 30 seconds less than any database or infrastructure imposed
#   connection time limit.
maximum-lifetime: 1800000 # 30 minutes

# This setting controls the maximum number of milliseconds that the plugin will wait for a
# connection from the pool, before timing out.
connection-timeout: 5000 # 5 seconds

# This setting allows you to define extra properties for connections.
#
# By default, the following options are set to enable utf8 encoding. (you may need to remove
# these if you are using PostgreSQL)
#   useUnicode: true
#   characterEncoding: utf8
#
# You can also use this section to disable SSL connections, by uncommenting the 'useSSL' and
# 'verifyServerCertificate' options below.
properties:
  useUnicode: true
  characterEncoding: utf8
  #useSSL: false
  #verifyServerCertificate: false

The prefix for all LuckPerms SQL tables.
- Change this if you want to use different tables for different servers.
table-prefix: 'luckperms_'
The prefix to use for all LuckPerms collections. Change this if you want to use different
collections for different servers. The default is no prefix.
mongodb-collection-prefix: ''
MongoDB ClientConnectionURI for use with replica sets and custom connection options
- See https://docs.mongodb.com/manual/reference/connection-string/
mongodb-connection-uri: ''
Define settings for a "split" storage setup.

- This allows you to define a storage method for each type of data.
- The connection options above still have to be correct for each type here.
split-storage:
Don't touch this if you don't want to use split storage!
enabled: false
methods:
# These options don't need to be modified if split storage isn't enabled.
user: h2
group: h2
track: h2
uuid: h2
log: h2
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                            UPDATE PROPAGATION & MESSAGING SERVICE                            |
|                                                                                |
|    Controls the ways in which LuckPerms will sync data & notify other servers of changes.    |
|     These options are documented on greater detail on the wiki under "Instant Updates".      |
|                                                                                |
+----------------------------------------------------------------------------------------------+
This option controls how frequently LuckPerms will perform a sync task.

- A sync task will refresh all data from the storage, and ensure that the most up-to-date data is
being used by the plugin.
- This is disabled by default, as most users will not need it. However, if you're using a remote
storage type without a messaging service setup, you may wish to set this to something like 3.
- Set to -1 to disable the task completely.
sync-minutes: -1
If the file watcher should be enabled.

- When using a file-based storage type, LuckPerms can monitor the data files for changes, and
automatically update when changes are detected.
- If you don't want this feature to be active, set this option to false.
watch-files: true
Define which messaging service should be used by the plugin.

- If enabled and configured, LuckPerms will use the messaging service to inform other connected
servers of changes.
- Use the command "/lp networksync" to manually push changes.
- Data is NOT stored using this service. It is only used as a messaging platform.

- If you decide to enable this feature, you should set "sync-minutes" to -1, as there is no need
for LuckPerms to poll the database for changes.

- Possible options:
=> sql       Uses the SQL database to form a queue system for communication. Will only work when
'storage-method' is set to MySQL or MariaDB. This is chosen by default if the
option is set to 'auto' and SQL storage is in use. Set to 'notsql' to disable this.
=> pluginmsg Uses the plugin messaging channels to communicate with the proxy.
LuckPerms must be installed on your proxy & all connected servers backend servers.
Won't work if you have more than one proxy.
=> lilypad   Uses LilyPad pub-sub to push changes. You need to have the LilyPad-Connect plugin
installed.
=> redis     Uses Redis pub-sub to push changes. Your server connection info must be configured
below.
=> auto      Attempts to automatically setup a messaging service using redis or sql.
messaging-service: sql
If LuckPerms should automatically push updates after a change has been made with a command.
auto-push-updates: true
If LuckPerms should push logging entries to connected servers via the messaging service.
push-log-entries: true
If LuckPerms should broadcast received logging entries to players on this platform.

- If you have LuckPerms installed on your backend servers as well as a BungeeCord proxy, you
should set this option to false on either your backends or your proxies, to avoid players being
messaged twice about log entries.
broadcast-received-log-entries: true
Settings for Redis.
Port 6379 is used by default; set address to "host:port" if differs
redis:
enabled: false
address: localhost
password: ''
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                                    CUSTOMIZATION SETTINGS                                    |
|                                                                                |
|              Settings that allow admins to customize the way LuckPerms operates.             |
|                                                                                |
+----------------------------------------------------------------------------------------------+
Controls how temporary permissions/parents/meta should be accumulated.

- The default behaviour is "deny".
- This behaviour can also be specified when the command is executed. See the command usage
documentation for more info.

- Possible options:
=> accumulate   durations will be added to the existing expiry time
=> replace      durations will be replaced if the new duration is later than the current
expiration
=> deny         the command will just fail if you try to add another node with the same expiry
temporary-add-behaviour: deny
Controls how LuckPerms will determine a users "primary" group.

- The meaning and influence of "primary groups" are explained in detail on the wiki.
- The preferred approach is to let LuckPerms automatically determine a users primary group
based on the relative weight of their parent groups.

- Possible options:
=> stored                  use the value stored against the users record in the file/database
=> parents-by-weight       just use the users most highly weighted parent
=> all-parents-by-weight   same as above, but calculates based upon all parents inherited from
both directly and indirectly
primary-group-calculation: parents-by-weight
If the plugin should check for "extra" permissions with users run LP commands.

- These extra permissions allow finer control over what users can do with each command, and who
they have access to edit.
- The nature of the checks are documented on the wiki under "Argument based command permissions".
- Argument based permissions are not static, unlike the 'base' permissions, and will depend upon
the arguments given within the command.
argument-based-command-permissions: false
If the plugin should check whether senders are a member of a given group before they're able to
edit the groups data or add/remove other users to/from it.
Note: these limitations do not apply to the web editor!
require-sender-group-membership-to-modify: false
If the plugin should send log notifications to users whenever permissions are modified.

- Notifications are only sent to those with the appropriate permission to receive them
- They can also be temporarily enabled/disabled on a per-user basis using
'/lp log notify <on|off>'
log-notify: true
Defines a list of log entries which should not be sent as notifications to users.

- Each entry in the list is a RegEx expression which is matched against the log entry description.
log-notify-filtered-descriptions:
- "parent add example"
Defines the options for prefix and suffix stacking.

- The feature allows you to display multiple prefixes or suffixes alongside a players username in
chat.
- It is explained and documented in more detail on the wiki under "Prefix & Suffix Stacking".

- The options are divided into separate sections for prefixes and suffixes.
- The 'duplicates' setting refers to how duplicate elements are handled. Can be 'retain-all',
'first-only' or 'last-only'.
- The value of 'start-spacer' is included at the start of the resultant prefix/suffix.
- The value of 'end-spacer' is included at the end of the resultant prefix/suffix.
- The value of 'middle-spacer' is included between each element in the resultant prefix/suffix.

- Possible format options:
=> highest                        Selects the value with the highest weight, from all values
held by or inherited by the player.

=> lowest                         Same as above, except takes the one with the lowest weight.

=> highest_own                    Selects the value with the highest weight, but will not
accept any inherited values.

=> lowest_own                     Same as above, except takes the value with the lowest weight.

=> highest_inherited              Selects the value with the highest weight, but will only
accept inherited values.

=> lowest_inherited               Same as above, except takes the value with the lowest weight.

=> highest_on_track_       Selects the value with the highest weight, but only if the
value was inherited from a group on the given track.

=> lowest_on_track_        Same as above, except takes the value with the lowest weight.

=> highest_not_on_track_   Selects the value with the highest weight, but only if the
value was inherited from a group not on the given track.

=> lowest_not_on_track_    Same as above, except takes the value with the lowest weight.

=> highest_from_group_     Selects the value with the highest weight, but only if the
value was inherited from the given group.

=> lowest_from_group_      Same as above, except takes the value with the lowest weight.

=> highest_not_from_group_ Selects the value with the highest weight, but only if the
value was not inherited from the given group.

=> lowest_not_from_group_  Same as above, except takes the value with the lowest weight.
meta-formatting:
prefix:
format:
- "highest"
duplicates: first-only
start-spacer: ""
middle-spacer: " "
end-spacer: ""
suffix:
format:
- "highest"
duplicates: first-only
start-spacer: ""
middle-spacer: " "
end-spacer: ""
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                            PERMISSION CALCULATION AND INHERITANCE                            |
|                                                                                |
|    Modify the way permission checks, meta lookups and inheritance resolutions are handled.   |
|                                                                                |
+----------------------------------------------------------------------------------------------+
The algorithm LuckPerms should use when traversing the "inheritance tree".

- Possible options:
=> breadth-first            See: https://en.wikipedia.org/wiki/Breadth-first_search
=> depth-first-pre-order    See: https://en.wikipedia.org/wiki/Depth-first_search
=> depth-first-post-order   See: https://en.wikipedia.org/wiki/Depth-first_search
inheritance-traversal-algorithm: depth-first-pre-order
If a final sort according to "inheritance rules" should be performed after the traversal algorithm
has resolved the inheritance tree.

"Inheritance rules" refers to things such as group weightings, primary group status, and the
natural contextual ordering of the group nodes.

Setting this to 'true' will allow for the inheritance rules to take priority over the structure of
the inheritance tree.

Effectively when this setting is 'true': the tree is flattened, and rules applied afterwards,
and when this setting is 'false':, the rules are just applied during each step of the traversal.
post-traversal-inheritance-sort: false
Defines the mode used to determine whether a set of contexts are satisfied.

- Possible options:
=> at-least-one-value-per-key   Set A will be satisfied by another set B, if at least one of the
key-value entries per key in A are also in B.
=> all-values-per-key           Set A will be satisfied by another set B, if all key-value
entries in A are also in B.
context-satisfy-mode: at-least-one-value-per-key
+----------------------------------------------------------------------------------------------+
| Permission resolution settings                                                               |
+----------------------------------------------------------------------------------------------+
If users on this server should have their global permissions applied.
When set to false, only server specific permissions will apply for users on this server
include-global: true
If users on this server should have their global world permissions applied.
When set to false, only world specific permissions will apply for users on this server
include-global-world: true
If users on this server should have global (non-server specific) groups applied
apply-global-groups: true
If users on this server should have global (non-world specific) groups applied
apply-global-world-groups: true
+----------------------------------------------------------------------------------------------+
| Meta lookup settings                                                                         |
+----------------------------------------------------------------------------------------------+
Defines how meta values should be selected.

- Possible options:
=> inheritance      Selects the meta value that was inherited first
=> highest-number   Selects the highest numerical meta value
=> lowest-number    Selects the lowest numerical meta value
meta-value-selection-default: inheritance
Defines how meta values should be selected per key.
meta-value-selection:
max-homes: highest-number
+----------------------------------------------------------------------------------------------+
| Inheritance settings                                                                         |
+----------------------------------------------------------------------------------------------+
If the plugin should apply wildcard permissions.

- If set to true, LuckPerms will detect wildcard permissions, and resolve & apply all registered
permissions matching the wildcard.
apply-wildcards: true
If LuckPerms should resolve and apply permissions according to the Sponge style implicit wildcard
inheritance system.

- That being: If a user has been granted "example", then the player should have also be
automatically granted "example.function", "example.another", "example.deeper.nesting",
and so on.
apply-sponge-implicit-wildcards: false
If the plugin should parse regex permissions.

- If set to true, LuckPerms will detect regex permissions, marked with "r=" at the start of the
node, and resolve & apply all registered permissions matching the regex.
apply-regex: true
If the plugin should complete and apply shorthand permissions.

- If set to true, LuckPerms will detect and expand shorthand node patterns.
apply-shorthand: true
If the plugin should apply Bukkit child permissions.

- Plugin authors can define custom permissions structures for their plugin, which will be resolved
and used by LuckPerms if this setting is enabled.
apply-bukkit-child-permissions: true
If the plugin should apply Bukkit default permissions.

- Plugin authors can define permissions which should be given to all users by default, or setup
permissions which should/shouldn't be given to opped players.
- If this option is set to false, LuckPerms will ignore these defaults.
apply-bukkit-default-permissions: true
If the plugin should apply attachment permissions.

- Other plugins on the server are able to add their own "permission attachments" to players.
- This allows them to grant players additional permissions which last until the end of the
session, or until they're removed.
- If this option is set to false, LuckPerms will not include these attachment permissions when
considering if a player should have access to a certain permission.
apply-bukkit-attachment-permissions: true
+----------------------------------------------------------------------------------------------+
| Extra settings                                                                               |
+----------------------------------------------------------------------------------------------+
Allows you to set "aliases" for the worlds sent forward for context calculation.

- These aliases are provided in addition to the real world name. Applied recursively.
- Remove the comment characters for the default aliases to apply.
world-rewrite:
world_nether: world
world_the_end: world
Define special group weights for this server.

- Group weights can also be applied directly to group data, using the setweight command.
- This section allows weights to be set on a per-server basis.
group-weight:
admin: 10
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                                      FINE TUNING OPTIONS                                     |
|                                                                                |
|     A number of more niche settings for tweaking and changing behaviour. The section also    |
| contains toggles for some more specialised features. It is only necessary to make changes to |
|                  these options if you want to fine-tune LuckPerms behaviour.                 |
|                                                                                |
+----------------------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------------------+
| Server Operator (OP) settings                                                                |
+----------------------------------------------------------------------------------------------+
Controls whether server operators should exist at all.

- When set to 'false', all players will be de-opped, and the /op and /deop commands will be
disabled.
enable-ops: true
Enables or disables a special permission based system in LuckPerms for controlling OP status.

- If set to true, any user with the permission "luckperms.autoop" will automatically be granted
server operator status. This permission can be inherited, or set on specific servers/worlds,
temporarily, etc.
- Additionally, setting this to true will force the "enable-ops" option above to false. All users
will be de-opped unless they have the permission node, and the op/deop commands will be
disabled.
- It is recommended that you use this option instead of assigning a single '*' permission.
auto-op: false
Defines if "opped" players should be able to use all LuckPerms commands by default.

- Set to false to only allow users who have the permissions access to the commands
commands-allow-op: true
+----------------------------------------------------------------------------------------------+
| Vault integration settings                                                                   |
+----------------------------------------------------------------------------------------------+
If Vault lookups for offline players on the main server thread should be enabled.

LuckPerms has a "catch" for plugins attempting to perform unsafe offline player data lookups
from the main server thread. This catch raises an exception (causes an error to occur) when unsafe
lookups are made, instead of allowing the lookup to happen, which would likely cause the server
to lag.

However, if you're willing to accept the consequences, the catch can be disabled by setting this
option to 'true.
vault-unsafe-lookups: false
Controls which group LuckPerms should use for NPC players when handling Vault requests.

- As NPCs aren't actually real players, LuckPerms does not load any user data for them. This
becomes an issue when plugins want to check for their permissions using Vault.
- As a solution, Vault checks for NPCs fallback to a group, which is defined below.
vault-npc-group: default
Controls how LuckPerms should consider the OP status of NPC players when handing Vault requests.

- If you want NPCs to have the same permissions as "normal" players, set this option to false.
- If you want NPCs to have OP status, set this option to true.
vault-npc-op-status: false
If the vault-server option below should be used.

- When this option is set to false, the server value defined above under "server" is used.
use-vault-server: false
The name of the server used within Vault operations.

- If you don't want Vault operations to be server specific, set this to "global".
- Will only take effect if use-vault-server is set to true above.
vault-server: global
If global permissions should be considered when retrieving meta or player groups
vault-include-global: true
If Vault operations should ignore any world arguments if supplied.
vault-ignore-world: false
+----------------------------------------------------------------------------------------------+
| Miscellaneous (and rarely used) settings                                                     |
+----------------------------------------------------------------------------------------------+
If LuckPerms should produce extra logging output when it handles logins.

- Useful if you're having issues with UUID forwarding or data not being loaded.
debug-logins: false
If LuckPerms should allow usernames with non alphanumeric characters.

- Note that due to the design of the storage implementation, usernames must still be 16 characters
or less.
allow-invalid-usernames: false
If LuckPerms should allow a users primary group to be removed with the 'parent remove' command.

- When this happens, the plugin will set their primary group back to default.
prevent-primary-group-removal: false
If LuckPerms should update the list of commands sent to the client when permissions are changed.
update-client-command-list: true
If LuckPerms should attempt to resolve Vanilla command target selectors for LP commands.
See here for more info: https://minecraft.gamepedia.com/Commands#Target_selectors
resolve-command-selectors: false
`

This is the config file of one of the servers (It's a factions server)
####################################################################################################
+----------------------------------------------------------------------------------------------+
|                                   __         __   ___  __         __                         |
|                        |    |  | /   |__/  |__) |__  |__)  |\/| /__                        |
|                        |___ _/ _, |  \  |    |___ |  \  |  | .__/                        |
|                                                                                |
|                                     https://luckperms.net                                    |
|                                                                                |
|  SOURCE CODE: https://github.com/lucko/LuckPerms                                             |
|  WIKI:        https://github.com/lucko/LuckPerms/wiki                                        |
|  BUG REPORTS: https://github.com/lucko/LuckPerms/issues                                      |
|                                                                                |
|  Each option in this file is documented and explained here:                                  |
|   ==>  https://github.com/lucko/LuckPerms/wiki/Configuration                                 |
|                                                                                |
|  New options are not added to this file automatically. Default values are used if an         |
|  option cannot be found. The latest config versions can be obtained at the link above.       |
+----------------------------------------------------------------------------------------------+
####################################################################################################
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                                      ESSENTIAL SETTINGS                                      |
|                                                                                |
|                   Important settings that control how LuckPerms functions.                   |
|                                                                                |
+----------------------------------------------------------------------------------------------+
The name of the server, used for server specific permissions.

- When set to "global" this setting is effectively ignored.
- In all other cases, the value here is added to all players in a "server" context.
- See: https://github.com/lucko/LuckPerms/wiki/Context
server: factions
If the servers own UUID cache/lookup facility should be used when there is no record for a player
already in LuckPerms.

- When this is set to 'false', commands using a player's username will not work unless the player
has joined since LuckPerms was first installed.
- To get around this, you can use a player's uuid directly in the command, or enable this option.
- When this is set to 'true', the server facility is used. This may use a number of methods,
including checking the servers local cache, or making a request to the Mojang API.
use-server-uuid-cache: false
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                                       STORAGE SETTINGS                                       |
|                                                                                |
|                Controls which storage method LuckPerms will use to store data.               |
|                                                                                |
+----------------------------------------------------------------------------------------------+
How the plugin should store data

- The various options are explained in more detail on the wiki:
https://github.com/lucko/LuckPerms/wiki/Storage-types

- Possible options:

|  Remote databases - require connection information to be configured below
|=> MySQL
|=> MariaDB (preferred over MySQL)
|=> PostgreSQL
|=> MongoDB

|  Flatfile/local database - don't require any extra configuration
|=> H2 (preferred over SQLite)
|=> SQLite

|  Readable & editable text files - don't require any extra configuration
|=> YAML (.yml files)
|=> JSON (.json files)
|=> HOCON (.conf files)
|=> TOML (.toml files)
|
| By default, user, group and track data is separated into different files. Data can be combined
| and all stored in the same file by switching to a combined storage variant.
| Just add '-combined' to the end of the storage-method, e.g. 'yaml-combined'

- A H2 database is the default option.
- If you want to edit data manually in "traditional" storage files, we suggest using YAML.
storage-method: MySQL
The following block defines the settings for remote database storage methods.

- You don't need to touch any of the settings here if you're using a local storage method!
- The connection detail options are shared between all remote storage types.
data:
Define the address and port for the database.
- The standard DB engine port is used by default
(MySQL: 3306, PostgreSQL: 5432, MongoDB: 27017)
- Specify as "host:port" if differs
address: <IP_ADDRESS>
The name of the database to store LuckPerms data in.
- This must be created already. Don't worry about this setting if you're using MongoDB.
database: xbitnetw_Luckyperms
Credentials for the database.
username: xbitnetw_estelthebest
password: 'Vj4m$#3k64G*Rpfv'
These settings apply to the MySQL connection pool.
- The default values will be suitable for the majority of users.
- Do not change these settings unless you know what you're doing!
pool-settings:
# Sets the maximum size of the MySQL connection pool.
# - Basically this value will determine the maximum number of actual
#   connections to the database backend.
# - More information about determining the size of connection pools can be found here:
#   https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
maximum-pool-size: 10

# Sets the minimum number of idle connections that the pool will try to maintain.
# - For maximum performance and responsiveness to spike demands, it is recommended to not set
#   this value and instead allow the pool to act as a fixed size connection pool.
#   (set this value to the same as 'maximum-pool-size')
minimum-idle: 10

# This setting controls the maximum lifetime of a connection in the pool in milliseconds.
# - The value should be at least 30 seconds less than any database or infrastructure imposed
#   connection time limit.
maximum-lifetime: 1800000 # 30 minutes

# This setting controls the maximum number of milliseconds that the plugin will wait for a
# connection from the pool, before timing out.
connection-timeout: 5000 # 5 seconds

# This setting allows you to define extra properties for connections.
#
# By default, the following options are set to enable utf8 encoding. (you may need to remove
# these if you are using PostgreSQL)
#   useUnicode: true
#   characterEncoding: utf8
#
# You can also use this section to disable SSL connections, by uncommenting the 'useSSL' and
# 'verifyServerCertificate' options below.
properties:
  useUnicode: true
  characterEncoding: utf8
  #useSSL: false
  #verifyServerCertificate: false

The prefix for all LuckPerms SQL tables.
- Change this if you want to use different tables for different servers.
table-prefix: 'luckperms_'
The prefix to use for all LuckPerms collections. Change this if you want to use different
collections for different servers. The default is no prefix.
mongodb-collection-prefix: ''
MongoDB ClientConnectionURI for use with replica sets and custom connection options
- See https://docs.mongodb.com/manual/reference/connection-string/
mongodb-connection-uri: ''
Define settings for a "split" storage setup.

- This allows you to define a storage method for each type of data.
- The connection options above still have to be correct for each type here.
split-storage:
Don't touch this if you don't want to use split storage!
enabled: false
methods:
# These options don't need to be modified if split storage isn't enabled.
user: h2
group: h2
track: h2
uuid: h2
log: h2
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                            UPDATE PROPAGATION & MESSAGING SERVICE                            |
|                                                                                |
|    Controls the ways in which LuckPerms will sync data & notify other servers of changes.    |
|     These options are documented on greater detail on the wiki under "Instant Updates".      |
|                                                                                |
+----------------------------------------------------------------------------------------------+
This option controls how frequently LuckPerms will perform a sync task.

- A sync task will refresh all data from the storage, and ensure that the most up-to-date data is
being used by the plugin.
- This is disabled by default, as most users will not need it. However, if you're using a remote
storage type without a messaging service setup, you may wish to set this to something like 3.
- Set to -1 to disable the task completely.
sync-minutes: -1
If the file watcher should be enabled.

- When using a file-based storage type, LuckPerms can monitor the data files for changes, and
automatically update when changes are detected.
- If you don't want this feature to be active, set this option to false.
watch-files: true
Define which messaging service should be used by the plugin.

- If enabled and configured, LuckPerms will use the messaging service to inform other connected
servers of changes.
- Use the command "/lp networksync" to manually push changes.
- Data is NOT stored using this service. It is only used as a messaging platform.

- If you decide to enable this feature, you should set "sync-minutes" to -1, as there is no need
for LuckPerms to poll the database for changes.

- Possible options:
=> sql       Uses the SQL database to form a queue system for communication. Will only work when
'storage-method' is set to MySQL or MariaDB. This is chosen by default if the
option is set to 'auto' and SQL storage is in use. Set to 'notsql' to disable this.
=> pluginmsg Uses the plugin messaging channels to communicate with the proxy.
LuckPerms must be installed on your proxy & all connected servers backend servers.
Won't work if you have more than one proxy.
=> lilypad   Uses LilyPad pub-sub to push changes. You need to have the LilyPad-Connect plugin
installed.
=> redis     Uses Redis pub-sub to push changes. Your server connection info must be configured
below.
=> auto      Attempts to automatically setup a messaging service using redis or sql.
messaging-service: sql
If LuckPerms should automatically push updates after a change has been made with a command.
auto-push-updates: true
If LuckPerms should push logging entries to connected servers via the messaging service.
push-log-entries: true
If LuckPerms should broadcast received logging entries to players on this platform.

- If you have LuckPerms installed on your backend servers as well as a BungeeCord proxy, you
should set this option to false on either your backends or your proxies, to avoid players being
messaged twice about log entries.
broadcast-received-log-entries: true
Settings for Redis.
Port 6379 is used by default; set address to "host:port" if differs
redis:
enabled: false
address: localhost
password: ''
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                                    CUSTOMIZATION SETTINGS                                    |
|                                                                                |
|              Settings that allow admins to customize the way LuckPerms operates.             |
|                                                                                |
+----------------------------------------------------------------------------------------------+
Controls how temporary permissions/parents/meta should be accumulated.

- The default behaviour is "deny".
- This behaviour can also be specified when the command is executed. See the command usage
documentation for more info.

- Possible options:
=> accumulate   durations will be added to the existing expiry time
=> replace      durations will be replaced if the new duration is later than the current
expiration
=> deny         the command will just fail if you try to add another node with the same expiry
temporary-add-behaviour: deny
Controls how LuckPerms will determine a users "primary" group.

- The meaning and influence of "primary groups" are explained in detail on the wiki.
- The preferred approach is to let LuckPerms automatically determine a users primary group
based on the relative weight of their parent groups.

- Possible options:
=> stored                  use the value stored against the users record in the file/database
=> parents-by-weight       just use the users most highly weighted parent
=> all-parents-by-weight   same as above, but calculates based upon all parents inherited from
both directly and indirectly
primary-group-calculation: parents-by-weight
If the plugin should check for "extra" permissions with users run LP commands.

- These extra permissions allow finer control over what users can do with each command, and who
they have access to edit.
- The nature of the checks are documented on the wiki under "Argument based command permissions".
- Argument based permissions are not static, unlike the 'base' permissions, and will depend upon
the arguments given within the command.
argument-based-command-permissions: false
If the plugin should check whether senders are a member of a given group before they're able to
edit the groups data or add/remove other users to/from it.
Note: these limitations do not apply to the web editor!
require-sender-group-membership-to-modify: false
If the plugin should send log notifications to users whenever permissions are modified.

- Notifications are only sent to those with the appropriate permission to receive them
- They can also be temporarily enabled/disabled on a per-user basis using
'/lp log notify <on|off>'
log-notify: true
Defines a list of log entries which should not be sent as notifications to users.

- Each entry in the list is a RegEx expression which is matched against the log entry description.
log-notify-filtered-descriptions:
- "parent add example"
Defines the options for prefix and suffix stacking.

- The feature allows you to display multiple prefixes or suffixes alongside a players username in
chat.
- It is explained and documented in more detail on the wiki under "Prefix & Suffix Stacking".

- The options are divided into separate sections for prefixes and suffixes.
- The 'duplicates' setting refers to how duplicate elements are handled. Can be 'retain-all',
'first-only' or 'last-only'.
- The value of 'start-spacer' is included at the start of the resultant prefix/suffix.
- The value of 'end-spacer' is included at the end of the resultant prefix/suffix.
- The value of 'middle-spacer' is included between each element in the resultant prefix/suffix.

- Possible format options:
=> highest                        Selects the value with the highest weight, from all values
held by or inherited by the player.

=> lowest                         Same as above, except takes the one with the lowest weight.

=> highest_own                    Selects the value with the highest weight, but will not
accept any inherited values.

=> lowest_own                     Same as above, except takes the value with the lowest weight.

=> highest_inherited              Selects the value with the highest weight, but will only
accept inherited values.

=> lowest_inherited               Same as above, except takes the value with the lowest weight.

=> highest_on_track_       Selects the value with the highest weight, but only if the
value was inherited from a group on the given track.

=> lowest_on_track_        Same as above, except takes the value with the lowest weight.

=> highest_not_on_track_   Selects the value with the highest weight, but only if the
value was inherited from a group not on the given track.

=> lowest_not_on_track_    Same as above, except takes the value with the lowest weight.

=> highest_from_group_     Selects the value with the highest weight, but only if the
value was inherited from the given group.

=> lowest_from_group_      Same as above, except takes the value with the lowest weight.

=> highest_not_from_group_ Selects the value with the highest weight, but only if the
value was not inherited from the given group.

=> lowest_not_from_group_  Same as above, except takes the value with the lowest weight.
meta-formatting:
prefix:
format:
- "highest"
duplicates: first-only
start-spacer: ""
middle-spacer: " "
end-spacer: ""
suffix:
format:
- "highest"
duplicates: first-only
start-spacer: ""
middle-spacer: " "
end-spacer: ""
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                            PERMISSION CALCULATION AND INHERITANCE                            |
|                                                                                |
|    Modify the way permission checks, meta lookups and inheritance resolutions are handled.   |
|                                                                                |
+----------------------------------------------------------------------------------------------+
The algorithm LuckPerms should use when traversing the "inheritance tree".

- Possible options:
=> breadth-first            See: https://en.wikipedia.org/wiki/Breadth-first_search
=> depth-first-pre-order    See: https://en.wikipedia.org/wiki/Depth-first_search
=> depth-first-post-order   See: https://en.wikipedia.org/wiki/Depth-first_search
inheritance-traversal-algorithm: depth-first-pre-order
If a final sort according to "inheritance rules" should be performed after the traversal algorithm
has resolved the inheritance tree.

"Inheritance rules" refers to things such as group weightings, primary group status, and the
natural contextual ordering of the group nodes.

Setting this to 'true' will allow for the inheritance rules to take priority over the structure of
the inheritance tree.

Effectively when this setting is 'true': the tree is flattened, and rules applied afterwards,
and when this setting is 'false':, the rules are just applied during each step of the traversal.
post-traversal-inheritance-sort: false
Defines the mode used to determine whether a set of contexts are satisfied.

- Possible options:
=> at-least-one-value-per-key   Set A will be satisfied by another set B, if at least one of the
key-value entries per key in A are also in B.
=> all-values-per-key           Set A will be satisfied by another set B, if all key-value
entries in A are also in B.
context-satisfy-mode: at-least-one-value-per-key
+----------------------------------------------------------------------------------------------+
| Permission resolution settings                                                               |
+----------------------------------------------------------------------------------------------+
If users on this server should have their global permissions applied.
When set to false, only server specific permissions will apply for users on this server
include-global: true
If users on this server should have their global world permissions applied.
When set to false, only world specific permissions will apply for users on this server
include-global-world: true
If users on this server should have global (non-server specific) groups applied
apply-global-groups: true
If users on this server should have global (non-world specific) groups applied
apply-global-world-groups: true
+----------------------------------------------------------------------------------------------+
| Meta lookup settings                                                                         |
+----------------------------------------------------------------------------------------------+
Defines how meta values should be selected.

- Possible options:
=> inheritance      Selects the meta value that was inherited first
=> highest-number   Selects the highest numerical meta value
=> lowest-number    Selects the lowest numerical meta value
meta-value-selection-default: inheritance
Defines how meta values should be selected per key.
meta-value-selection:
max-homes: highest-number
+----------------------------------------------------------------------------------------------+
| Inheritance settings                                                                         |
+----------------------------------------------------------------------------------------------+
If the plugin should apply wildcard permissions.

- If set to true, LuckPerms will detect wildcard permissions, and resolve & apply all registered
permissions matching the wildcard.
apply-wildcards: true
If LuckPerms should resolve and apply permissions according to the Sponge style implicit wildcard
inheritance system.

- That being: If a user has been granted "example", then the player should have also be
automatically granted "example.function", "example.another", "example.deeper.nesting",
and so on.
apply-sponge-implicit-wildcards: false
If the plugin should parse regex permissions.

- If set to true, LuckPerms will detect regex permissions, marked with "r=" at the start of the
node, and resolve & apply all registered permissions matching the regex.
apply-regex: true
If the plugin should complete and apply shorthand permissions.

- If set to true, LuckPerms will detect and expand shorthand node patterns.
apply-shorthand: true
If the plugin should apply Bukkit child permissions.

- Plugin authors can define custom permissions structures for their plugin, which will be resolved
and used by LuckPerms if this setting is enabled.
apply-bukkit-child-permissions: true
If the plugin should apply Bukkit default permissions.

- Plugin authors can define permissions which should be given to all users by default, or setup
permissions which should/shouldn't be given to opped players.
- If this option is set to false, LuckPerms will ignore these defaults.
apply-bukkit-default-permissions: true
If the plugin should apply attachment permissions.

- Other plugins on the server are able to add their own "permission attachments" to players.
- This allows them to grant players additional permissions which last until the end of the
session, or until they're removed.
- If this option is set to false, LuckPerms will not include these attachment permissions when
considering if a player should have access to a certain permission.
apply-bukkit-attachment-permissions: true
+----------------------------------------------------------------------------------------------+
| Extra settings                                                                               |
+----------------------------------------------------------------------------------------------+
Allows you to set "aliases" for the worlds sent forward for context calculation.

- These aliases are provided in addition to the real world name. Applied recursively.
- Remove the comment characters for the default aliases to apply.
world-rewrite:
world_nether: world
world_the_end: world
Define special group weights for this server.

- Group weights can also be applied directly to group data, using the setweight command.
- This section allows weights to be set on a per-server basis.
group-weight:
admin: 10
+----------------------------------------------------------------------------------------------+
|                                                                                |
|                                      FINE TUNING OPTIONS                                     |
|                                                                                |
|     A number of more niche settings for tweaking and changing behaviour. The section also    |
| contains toggles for some more specialised features. It is only necessary to make changes to |
|                  these options if you want to fine-tune LuckPerms behaviour.                 |
|                                                                                |
+----------------------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------------------+
| Server Operator (OP) settings                                                                |
+----------------------------------------------------------------------------------------------+
Controls whether server operators should exist at all.

- When set to 'false', all players will be de-opped, and the /op and /deop commands will be
disabled.
enable-ops: true
Enables or disables a special permission based system in LuckPerms for controlling OP status.

- If set to true, any user with the permission "luckperms.autoop" will automatically be granted
server operator status. This permission can be inherited, or set on specific servers/worlds,
temporarily, etc.
- Additionally, setting this to true will force the "enable-ops" option above to false. All users
will be de-opped unless they have the permission node, and the op/deop commands will be
disabled.
- It is recommended that you use this option instead of assigning a single '*' permission.
auto-op: false
Defines if "opped" players should be able to use all LuckPerms commands by default.

- Set to false to only allow users who have the permissions access to the commands
commands-allow-op: true
+----------------------------------------------------------------------------------------------+
| Vault integration settings                                                                   |
+----------------------------------------------------------------------------------------------+
If Vault lookups for offline players on the main server thread should be enabled.

LuckPerms has a "catch" for plugins attempting to perform unsafe offline player data lookups
from the main server thread. This catch raises an exception (causes an error to occur) when unsafe
lookups are made, instead of allowing the lookup to happen, which would likely cause the server
to lag.

However, if you're willing to accept the consequences, the catch can be disabled by setting this
option to 'true.
vault-unsafe-lookups: false
Controls which group LuckPerms should use for NPC players when handling Vault requests.

- As NPCs aren't actually real players, LuckPerms does not load any user data for them. This
becomes an issue when plugins want to check for their permissions using Vault.
- As a solution, Vault checks for NPCs fallback to a group, which is defined below.
vault-npc-group: default
Controls how LuckPerms should consider the OP status of NPC players when handing Vault requests.

- If you want NPCs to have the same permissions as "normal" players, set this option to false.
- If you want NPCs to have OP status, set this option to true.
vault-npc-op-status: false
If the vault-server option below should be used.

- When this option is set to false, the server value defined above under "server" is used.
use-vault-server: false
The name of the server used within Vault operations.

- If you don't want Vault operations to be server specific, set this to "global".
- Will only take effect if use-vault-server is set to true above.
vault-server: global
If global permissions should be considered when retrieving meta or player groups
vault-include-global: true
If Vault operations should ignore any world arguments if supplied.
vault-ignore-world: false
+----------------------------------------------------------------------------------------------+
| Miscellaneous (and rarely used) settings                                                     |
+----------------------------------------------------------------------------------------------+
If LuckPerms should produce extra logging output when it handles logins.

- Useful if you're having issues with UUID forwarding or data not being loaded.
debug-logins: false
If LuckPerms should allow usernames with non alphanumeric characters.

- Note that due to the design of the storage implementation, usernames must still be 16 characters
or less.
allow-invalid-usernames: false
If LuckPerms should allow a users primary group to be removed with the 'parent remove' command.

- When this happens, the plugin will set their primary group back to default.
prevent-primary-group-removal: false
If LuckPerms should update the list of commands sent to the client when permissions are changed.
update-client-command-list: true
If LuckPerms should attempt to resolve Vanilla command target selectors for LP commands.
See here for more info: https://minecraft.gamepedia.com/Commands#Target_selectors
resolve-command-selectors: false

All servers are connected to the same MySQL database btw

Just read the message.. it tells you what the problem is.
[20:32:07] [User Authenticator #3/WARN]: [LuckPerms] LuckPerms already has data for player 'DarkProvider' - but this data is stored under a different UUID.
[20:32:07] [User Authenticator #3/WARN]: [LuckPerms] 'DarkProvider' has previously used the unique ids [75234c82-b802-39e2-a35a-172159e00e0b] but is now connecting with '0156f7f5-4cd6-4a94-87a2-0ad1f376b076'
[20:32:07] [User Authenticator #3/WARN]: [LuckPerms] The UUID the player is connecting with now is Mojang-assigned (type 4). This implies that one of the other servers in your network is not authenticating correctly.
[20:32:07] [User Authenticator #3/WARN]: [LuckPerms] If you're using BungeeCord/Velocity, please ensure that IP-Forwarding is setup correctly on all of your backend servers!
[20:32:07] [User Authenticator #3/WARN]: [LuckPerms] See here for more info: https://github.com/lucko/LuckPerms/wiki/Network-Installation#pre-setup
[20:32:07] [User Authenticator #3/INFO]: UUID of player DarkProvider is 0156f7f5-4cd6-4a94-87a2-0ad1f376b076

To fix it make sure your bungeecord has ip forwarding enabled and your backend servers have bungee mode enabled.


Investigate switching to camera_android_camerax

What
Google announced a newly released camera_android_camerax (0.5) pub.dev package which switches camera to CameraX (there are still a LOT of things missing, like flash, focus…, but they announce their intention to implemeent it eventually).
Overtime, it could reduce maintenance cost of mobile_scanner, and custom code.
It might be worth weighting advantages and effort, and investigating switching to camera_android_camerax
https://pub.dev/packages/camera_android_camerax

If we were to switch to camera and defer to that for the texture, we'd have to drop MacOS support, since it's not a supported platform.
However, we could try to use our MacOS implementation as a starting point.
As a side benefit: camera_windows exists, but I'm not sure if its feature is complete enough yet.
I also don't know if Windows has a library for scanning barcodes.

I think that this can be a lot easier to implement once we have the platform interface work set up.
Then we can rely on camera_android_camerax for the Android implementation, but keep our own implementations for iOS/MacOS as-is (since it only affects Android then)


conda-suggest-conda-forge 2020.10.30

Merge only after success.
This pull request was auto-generated by rever

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Blender: Blend File Family

Duplicate of PR #4321 targeting 3.15.x release.

This release will not go to 3.15.x, only https://github.com/ynput/OpenPype/pull/4321 go to develop


caching

we got it working and integrating the package with the CLI-tooling.
We do inject now the username/pwd for connectionstrings when we create a datacontext in .net core.
But the retrieval takes every time a couple of seconds.
So now our execution time is really slow but the password is not change in the meantime.
Is it an option to build in some caching mechanism? Where I can set the caching time to x minutes for example?

Can you give me more details about your projet? .NET version? Type of project (ASP.NET, Web API, Blazor, Winforms)? How are you using 1Password .NET (in the constructor, in a method, using dependency injection)?

Hi, I have build several webservices and a console app for my product where I use your work. Thanks for the good work by the way!
I do not use the dependency injector related stuff for your library.
But I do have to request really often in the process some records from 1password. I see that every request takes relatively long.
So I have now an in-memory cache of those records from 1password to speed it up because especially in my webservices it takes too long otherwise.

Thanks for the kind words!
I feel like implementing caching internally to this project would fall outside of its scope. Not to mention that it would add additional complexity and perhaps even some security issues, so both reasons, I believe your approach is probably what would work best considering your use case.
I'm glad that this project is useful for you. All the best.


Switch from pandas to SQLite for the data loader

Upload to s3 is now also 2x faster.

Nice work Sam!


Flow support

Describe the feature
I saw the old issue here https://github.com/swc-project/swc/issues/174 but I was wondering, since it's been five years, if you have considered adding Flow support.
It's being actively developed and still used in big projects. Your claim to be a drop-in replacement for babel doesn't really hold water without it IMO.
Babel plugin or link to the feature description
No response
Additional context
No response

https://github.com/swc-project/swc/pull/9114

awesome!


annotation for classes that the scenario factsheet should neglect

Description of the issue
From OEKG:
annotation for classes that oekg should neglect: oekg ignore = true
Ideas of solution
If you already have ideas for the solution describe them here
Workflow checklist

[ ] I discussed the issue with someone else than me before working on a solution
[ ] I already read the latest version of the workflow for this repository
[ ] The goal of this ontology is clear to me

I am aware that

[ ] every entry in the ontology should have a definition
[ ] classes should arise from concepts rather than from words

annotation for classes that oekg should neglect: oekg ignore = true

Probably not the oekg should ignore these classes but the scenario factsheet, right?

Issue https://github.com/OpenEnergyPlatform/oekg/issues/19 in the OEKG has shown a potential second use case: to mark classes that could be used as a descriptor in a bundle.
So what about: An annotation that specifies how an entity should be used by the OEKG or the scenario bundles.
Allowed values:

ignore: Entity will not by shown in hierarchical structures (e.g. of sectors or energy carriers)
descriptor: Entity will be used in the scenario bundles as option to be selected as descriptor.

Since the descriptor annotation is requested for in https://github.com/OpenEnergyPlatform/oeplatform/issues/1718 again, and there is an agreement on that in https://github.com/OpenEnergyPlatform/oekg/issues/19, I will add this annotation now, so that it can be used for the bundles.


Disable RCF in the JVM during CLJS build (in :require-macros scenario)

When the CLJ REPL and Shadow are sharing JVM, RCF tests are enabled at the CLJ repl and Shadow needs to disable JVM RCF tests during incremental builds because :require-macros in a CLJS file will cause the CLJ files to load, running tests if enabled.
https://shadow-cljs.github.io/docs/UsersGuide.html#compile-stages
(defn rcf-shadow-hook
  {:shadow.build/stage #{:configure :flush}}
  [build-state & args]
  (case (:shadow.build/stage build-state)
    :configure (enable! false)
    :flush (enable!))
  build-state)

I am running with this patch locally for a bit

See https://clojurians.slack.com/archives/C7Q9GSHFV/p1688040336095859?thread_ts=1688031756.398229&cid=C7Q9GSHFV


class EncoderDecoder last element of output of decoder does not match

Here is the partial output of my code:
python3 ch9-p247-encdec.py
printFnc: func:  <function namestr at 0x7f0359f5adc0>
printFnc: func:  <function Linear.__init__ at 0x7f0359f79160>
--------------------------------
['outputs'] :  <class 'torch.Tensor'>
torch.Size([1, 2, 2])
tensor([[[-0.2339,  0.4702],
         **[-0.2634,  0.4622]]], grad_fn=<CopySlices>)**
--------------------------------
--------------------------------
['outputs_from_src_seq'] :  <class 'torch.Tensor'>
torch.Size([1, 2, 2])
tensor([[[-0.2339,  0.4702],
         **[-0.2634,  0.4622]]], grad_fn=<CopySlices>)**

code sources is at:
https://gitlab.com/codelabs8265339/codelab-gpu/-/blob/dev-gpu-sbs/ml/tf/tf-from-scratch/3/code-exercises/ch9/ch9-p247-encdec.py?ref_type=heads
Basically I copied line by line from around p247.
The previous example using separate encoder and decoder class directly (w/o using encoderDecoder) class, output of the decoder was not matching (although encoder's does) which I fixed (matched output) by setting seed reset at 21 before initialization of both encoder and decoder instantiation:

torch.manual_seed(21)

encoder = Encoder(n_features=2, hidden_dim=2)

hidden_seq = encoder(source_seq) # output is N, L, F
printTensor(hidden_seq, globals(), "full")
hidden_final = hidden_seq[:, -1:]   # takes last hidden state
printTensor(hidden_final, globals(), "full")

torch.manual_seed(21)

decoder = Decoder(n_features=2, hidden_dim=2)
decoder.init_hidden(hidden_seq)

I tried to do same trick before instantiation of encoderDecoder class but this time luck did not hit me:
# create encoder

torch.manual_seed(21)
encoder = Encoder(n_features=2, hidden_dim=2)

# creaet decoder

torch.manual_seed(21)
decoder = Decoder(n_features=2, hidden_dim=2)

torch.manual_seed(21)
encdec=EncoderDecoder(encoder, decoder, input_len=2, target_len=2, teacher_forcing_prob=0.5)

Hi @jdgh000 ,
I believe the reproducibility issue boils down to the teacher_forcing_prob argument.  To test the reproducibility of the EncoderDecoder class against its two components, Encoder and Decoder, we have to set it to 1.0  so the next token is always generated based on the previous real token. Otherwise, sometimes the EncoderDecoder class will randomly choose the previously generated token as starting point for the prediction.
Once we set the probability to 1.0, the outputs should match. First, let's use the EncoderDecoder class (notice I changed the seed just to illustrate my point with a different set of outputs):
# create encoder
torch.manual_seed(23)
encoder = Encoder(n_features=2, hidden_dim=2)
# creaet decoder
torch.manual_seed(23)
decoder = Decoder(n_features=2, hidden_dim=2)

encdec = EncoderDecoder(encoder, decoder, input_len=2, target_len=2, teacher_forcing_prob=1.0)
encdec.train() # teacher forcing can only happen in training mode
encdec(full_seq)

The output:
tensor([[[ 0.2269, -0.6615],
         [ 0.2650, -0.6666]]], grad_fn=<CopySlices>)

Now, if we do it manually:
torch.manual_seed(23) # matching seed
encoder = Encoder(n_features=2, hidden_dim=2)
hidden_seq = encoder(source_seq) # output is N, L, F
hidden_final = hidden_seq[:, -1:]   # takes last hidden state
print(hidden_seq)

torch.manual_seed(23)  # matching seed
decoder = Decoder(n_features=2, hidden_dim=2)
decoder.init_hidden(hidden_seq)

# Generation loop
inputs = source_seq[:, -1:]

# HERE: so it's always teacher forcing and we guarantee reproducibility
teacher_forcing_prob = 1.0

target_len = 2
for i in range(target_len):
    print(f'Hidden: {decoder.hidden}')
    out = decoder(inputs)
    print(f'Output: {out}\n')
    # If it is teacher forcing
    if torch.rand(1) <= teacher_forcing_prob:
        # Takes the actual element
        inputs = target_seq[:, i:i+1]
    else:
        # Otherwise uses the last predicted output
        inputs = out

The output is:
tensor([[[ 0.3565, -0.0588],
         [ 0.1863, -0.1898]]], grad_fn=<TransposeBackward1>)
Hidden: tensor([[[ 0.1863, -0.1898]]], grad_fn=<PermuteBackward0>)
Output: tensor([[[ 0.2269, -0.6615]]], grad_fn=<ViewBackward0>)

Hidden: tensor([[[ 0.1462, -0.2929]]], grad_fn=<StackBackward0>)
Output: tensor([[[ 0.2650, -0.6666]]], grad_fn=<ViewBackward0>)

Notice that the two printed outputs (tensor([[[ 0.2269, -0.6615]]], grad_fn=<ViewBackward0>) and tensor([[[ 0.2650, -0.6666]]], grad_fn=<ViewBackward0>)) do match the overall output produced by the encdec object now.
I hope it helps.
Best,
Daniel

ok so that teacher forcing prob is set to 1.0? I was not sure about it as i thought that happened before introducing teacher forcing. I may be wrong on this i will try that and see if it works. thx


Release 0.20.1

Checklist

[x] Check dependencies.

[x] Check that all dependencies use the release version.
[x] Check that dependencies are up-to-date with cargo update.

[x] Submit PR
[x] Tag annotated with version number
[x] Push tags

The issue has been resolved, so I'll close it


fill_in does not trigger a change event

While I use fill_in on a textarea, a change event is not triggered when the textarea loses focus. However, doing it manually in Firefox always triggers this event.
This is on version 1.1.2 with the firefox driver.

That's odd -- I would expect it to. Can you show/upload some code to reproduce this?
I wonder if this is a Selenium issue. The Capybara code that fills in textareas is pretty simple:
29-    elsif tag_name == 'textarea' or tag_name == 'input'
30-      resynchronize do
31-        native.clear
32-        native.send_keys(value.to_s)
33-      end
34-    end

(Not cc'ing Jari yet until we have some code to reproduce.)
...
Actually, looking at the Stackoverflow answers your linked in https://github.com/derickbailey/backbone.modelbinding/issues/55, I'm increasingly suspecting it's something between Firefox and Selenium.

I'm having trouble extracting the code from my app, else I would provide a reduced test case. But here are the two things that failed:
it "should keep the contents when switching between sections" do
  ...
  fill_in "setup", :with => "echo a different command"
  # page.execute_script("$('#setup').trigger('change');") # shouldn't need this

  click_link "tests"
  click_link "setup"
  find_field("setup").value.should == "echo a different command"
end

So click_link is not causing the change event to be triggered. To make matters more complicated this does work maybe 25% of the time!
Similarly:
it "should be saved when we click save" do
  fill_in "setup", :with => "echo c"
  # page.execute_script("$('#setup').trigger('change');") # shouldn't need this

  fill_in "dependencies", :with => "echo d"
  # page.execute_script("$('#dependencies').trigger('change');") # shouldn't need this

  click_link "Now set up your tests =>"

  fill_in "test", :with => "echo a"
  # page.execute_script("$('#test').trigger('change');") # shouldn't need this

  fill_in "extra", :with => "echo b"
  # page.execute_script("$('#extra').trigger('change');") # shouldn't need this

  click_button "Save commands and run your tests"

  sleep 0.5 # wait for the PUT to save
  p =<EMAIL_ADDRESS>
  p.test.should == "echo a"
  p.extra.should == "echo b"
  p.setup.should == "echo c"
  p.dependencies.should == "echo d"
end

So in this case, when I debugged I found that other fill_in calls also don't cause the event to be triggered. Note that it works fine if  I reenable the execute_script calls.

I'm a little confused as to why this is a capybara issue worth discussing/addressing when the underlying driver is selenium, but not when capybara-webkit is involved.  Can you please help me (and future readers arriving here via google search) understand the technical distinction?

@Sporky023 because the capybara project provides the driver for interfacing to selenium, the capybara-WebKit project is separate - I'm now going to lock this issue


Sender - Texture Methd - Image in spout cropped by player window size, wrong aspect ratio

I use Sender with Texture Method.
It seems that resolution or aspect ratio of rendered image is taken from main camera or (game view) - rather than the render texture
Then it's blit into proper sized Spout buffer render texture.
When I change size of a game view (or built player), Image in spout gets cropped accordingly
Unity 2020.3.26
Built-in RP
GTX2080S

I can't reproduce the issue on 2021.2.8f1 with the built-in render pipeline.

I also checked with 2020.3.26, but it doesn't reproduce.

I'm closing this issue now as "not reproducible". Please reopen it if it still reproduces (attach a minimal project for reproduction in that case).


Updated middleman - but JS/stylesheets now not working

Hi guys. I noticed that when I ran a gem list commend, I saw middleman (4.2.1, 3.4.1) - so, in my repo I opened Gemfile and updated the gem accordingly:
From gem "middleman", "~>3.4.1"
To gem "middleman", "~>4.2.1"
After  abundle install to double check everything was working, I successfully started things up via bundle exec middleman however, all my JS files/stylesheets aren't compiling. The files are definitely there, but Chrome is giving me a 404
Failed to load resource: the server responded with a status of 404 (Not Found)   http://localhost:4567/sass/all.css
Any hints?

A quick guess is that your files don’t have the full list of extensions. For example, a SASS file should be named all.css.scss. all.scss results in 404 in MM4.

Sure thing @vvasabi - so would this apply to every single .scss file? As an example; here's a tree view of my stylesheets. You're saying in order for things to compile properly, they'd all need _<name>.css.scss titles?
Thanks :)

Ones that are @imported by Sass do not need the .css extension. Ones that are <link />ed do.

No luck. Here's the output.

 (MM4 removed a lot of things from the core.) Did that syntax work with MM3? If so, you may have to enable additional extensions to get the old behaviour back.
Alternatively, you can always @import individual files. If you use a third party library, there is a good chance that they provide a file that imports everything else for you.

Yep, the syntax seen above worked fine with MM3. I'll do some investigating and yes, if the * doesn't work, I'll just list out things individually :)

No luck. And now I've run into bigger issues. I'll close this off for now and open something else.

@vvasabi Renaming the file as .css.scss worked for me. Thanks.


Add basic benchmarking script

Provide a script for basic benchmarking of standardized XGBoost models

CI is having an issue with the new LFS objects in this branch. Will rerun tests once that is sorted.


NATS protocol improvements

Addresses:

#258: You can create Consumers with the WithQueueSubscriber("queue-name") option
#257: With the v2 refactor, you no longer need to wait for subscriptions to be created because calls to Receive(ctx) will block until either messages are received or ctx is closed
#316: Follows the same pattern as kafka and STAN, with two constructors for one with an existing connection and one without.

Added integration tests for NATS, and updated the sample cmds

Oops, I've branched off my STAN branch.. hold with me while I rebase

Awesome!
LGTM


Example not working on MacOS Sierra

Hi,
I cloned the repo as instructed than ran npm install and npm start, the app starts, but is doesn't render anything.

No errors are logged on console, I don't know where to start to debug this, any hint appreciated.

Same problem happening for me.


As far as development go?

I were spending more than ten hours straight reading about this wonderful language it compares much better than R module Morpho and it's well capable as far as development go, where to find packages or Libraries for the language. And how to expand it once I have a C language library?

Hey @eihabhala, thanks for the kind feedback and sorry for the slow response! We're in the process of building out the morpho ecosystem, so check in the Morpho-lang organization to see some of the extensions and packages under development. Are you interested in particular libraries?
You may also be interested in checking out the dev-guide which talks a bit more on how to extend morpho with C packages (or any other language that links to C).
Finally, consider joining the morpho Slack community: https://join.slack.com/t/morphoco/shared_invite/zt-1o6azavwl-XMtjjFwxW~P6C8rc~YbBlA

I'm closing this since there's no action to be taken. Please feel free to reach out @eihabhala with suggestions, questions or feedback!

Thanks have joined the group


PIP 176: Refactor Doc Bot

Movitation
Discussed with the community: https://lists.apache.org/thread/tz7x73lnkvcg3vqmb9r26s4p6md5sb8y
Issues
When fixing https://github.com/apache/pulsar/issues/15732, @maxsxu found that the doc Bot was implemented by modifying dist rather than src, which makes it hard to maintain and scale.
Consequently, he suggests refactoring the doc Bot along with resolving the following issues in Bot:
Scenario 1
Issue
This PR was marked with doc-related labels and then removed. No doc-related label is marked for this PR.
Expected behavior
In this case, this PR should be labeled w/ doc-label-missing.

Scenario 2
Issue
Doc Bot only works for master change.
Expected behavior
Doc Bot should work for all branches and label all PRs.

Scenario 3
Issue
Bot labels this PR with several doc labels.
Expected behavior
Bot should label a PR with only a doc label.

Improvements
Can we enforce the Bot to execute the following commands?

cherry-pick may not fit because it works between branches and we want to work between folders. Need to research more.

References
Pulsar Bot

Instructions
Implementation process
Flowchart
Script file

Thanks @Anonymitaet brings this out.
More context from the previous maintainer:

Current doc-label-check inspired from https://github.com/harupy/auto-labeling. During the doc bot development, just been modifying the compiled dist/index.js to quickly satisfy requirements.

So from all perspectives, refactoring is necessary. I'll be working on this to make the doc Bot more maintainable extendable.

@maxsxu I've added more improvements as we discussed just now

The new documentation bot is implemented at https://github.com/apache/pulsar-test-infra/pull/43


BasicConsumeArguments: rename no_ack since it is confusing

While no_ack is indeed a protocol-level field name, it is confusing. For basic.consume in the API, other clients have generally adopted "auto ack" for the name (or "manual ack", which I like even more).
So I suggest that the field is renamed to auto_ack and a convenience method (default) is introduced for both modes.
Happy to work on a PR if it would be accepted.

rename the public field is also backward compatible, do you have proposal to make a backward compatible change?

Well, the builder pattern can have one more method. Maybe without using the macro that defines all methods right now.
More importantly, after we introduce a new method, all examples should be updated to use it.

Good to me.
I meant rename public field is non-backward compatible


perf-linux installation failure

I am failing to install perf-linux on nix-unstable right now:
$ nix-env -i perf-linux
...
  LD       plugin_jbd2-in.o
ld: cannot load ld backend library 'libld_elf_x86_64.so': libld_elf_x86_64.so: cannot open shared object file: No such file or directory

What more details should I provide?

@lukego perf fails on kernel 4.1 and 4.2 only

#9643 for an (arguably hacky) fix.


Docker image: add vim and nettools (netstat)

Motivation
Now that we have rootless images the user (system administrator in this case) cannot install new tools easily, so it is better to add to the base image some common tools, like "vim" and "netstat"
e. What is the problem you're trying to solve.*
Modifications
Add "vim" and "netstat" and "unzip" to the base image.
The image will become a little bigger but it is worth
Verifying this change
This change is already covered by existing tests, the integration tests.

IIRC you switched to some lightweight docker image the integration tests

There's the java-test-image available added by #9625 . The docker file for that is https://github.com/apache/pulsar/blob/master/tests/docker-images/java-test-image/Dockerfile .
java-test-image isn't used for integration tests in CI atm. There's support for that, but it's not used in CI.

@lhotari thanks

@sijie sure I know.
this image will be used by many users.
Now that we are rootless it is very difficult to operate inside the containers.
I believe that we should add some guide in the docs about to work in a rootless world
on the other hand we should provide the most common tools.
without "vim" or "nano" it is impossible to edit files easily on Linux
the same applies to "netstat" it is something that everyone is used to use
if you deploy Pulsar using the Open Source docker images and the helm chart you should be able to work

@eolivelli thanks for your contribution. For this PR, do we need to update docs?

@sijie @addisonj @michaeljmarshall  do you have some suggestion about how to help users work on the pods now that we are rootless ?

Given that we already include several pulsar clients in the basic pulsar docker image, it's probably reasonable to include these three packages as the PR proposes. If we change direction and have smaller docker images or if we need to add many more packages, we could discuss have "debug" images and limiting the packages shipped in the basic pulsar and pulsar-all images.

It is really a pain to upgrade to 2.8.0 docker images (a part from the fact that you have to fix the owner of the files on the bk and zk pods).
I wonder if anyone will be happy to upgrade to 2.8.0 docker images.
I would like that users won't be forced to build their own custom docker images or to be forced to use third-party docker images just because they do not have a way to edit files (vim) or to see open connections (netstat)

I wonder if anyone will be happy to upgrade to 2.8.0 docker images.

I think security conscious users/companies will be happy to see we're moving in this direction. Further, the Pulsar 2.8.0 image is the first pulsar image that is compliant with Open Shift's requirements to run a container as a random non root user.
We can mitigate much of the complexity in the helm chart. In the official Helm chart, we are going to override the default user for the bookkeeper and zookeeper containers so they run as root until a user opts in to running them as non root.

I would like that users won't be forced to build their own custom docker images or to be forced to use third-party docker images just because they do not have a way to edit files (vim) or to see open connections (netstat)

I agree that we want to provide a docker image that is useful to the majority of our users. A "debug" docker image could eventually make sense too, but for now, we can just add in these packages.

Give we have reverted the docker image from rootless to a root image, we should hold on to this change and push the discussion later when we switched back to rootless.

@sijie

Give we have reverted the docker image from rootless to a root image, we should hold on to this change and push the discussion later when we switched back to rootless.

Makes sense to me.
We should think more about the impact of rootless container images.
I am keeping open this PR and add it to 2.9.0, so that we won't forget

The pr had no activity for 30 days, mark with Stale label.


Why there's no need to pay attention to the dc.tc.prpr domain in cases where the page request fails？

hi.sir:
For the requirements of prpr in section 2.1.3 of the spec, the scenario is as follows:
When a page request fails to write into the memory's PQ queue and the IOMMU needs to send a page request response, why is it unnecessary to consider the dc.tc.prpr field in the pid domain of the page request response information?
Thanks for your reply in advance.

Why is it unnecessary to check the dc.tc.prpr field in the page request response information issued by the IOMMU with a failure response?

if the prpr could be determined then it is used. The cases where prpr cannot be determined lead to a response failure and in those cases the PRI at the device gets disabled.

For the two scenarios in spec 3.7 where the IOMMU generates a Response Failure for page request responses and can retrieve the correct dc.tc.prpr, why is it still unnecessary to check prpr?

Page-request queue is not enabled (pqcsr.pqen == 0 or pqcsr.pqon == 0)
Page-request queue encountered a memory access fault (pqcsr.pqmf == 1)

The normative reference is:

When the IOMMU generates the response, the status field of the response depends on the cause of the error. If a fault condition prevents locating a valid device context then the PRPR value assumed is 0.

If the PRPR can be determined then it applies. I see there is some contradicting text on page 41 which needs to be updated to clarify this.

Hi.sir:
if the response code is Response Failure by pq not enable or pq memory fault, the PRPR is can be find in device context. Hope to update it if necessory. Thanks.
https://github.com/riscv-non-isa/riscv-iommu/blob/main/iommu_ref_model/libiommu/src/iommu_ats.c#L343-L354
    if ( response_code == INVALID_REQUEST || response_code == SUCCESS ) {
        if ( PRPR == 1 ) {
            prgr.PV = pr->PV;
            prgr.PID = pr->PID;
        } else {
            prgr.PV = 0;
            prgr.PID = 0;
        }
    } else {
        prgr.PV = pr->PV;
        prgr.PID = pr->PID;
    }

@ved-rivos

I researched this a bit more.
The specification states:

For IOMMU-generated "Page Request Group Response" messages that have status Invalid Request or Success, the PRG-response-PASID-required (PRPR) bit when set to 1 indicates that the IOMMU response message should include a PASID if the associated "Page Request" had a PASID. For IOMMU-generated "Page Request Group Response" with response code set to Response Failure, if the "Page Request" had a PASID then response is generated with a PASID.

This is consistent with the model.
While the two cases you highlighted, the page queue is not enabled or encountered a memory fault could have been treated differently for the response failure case, the decision was not to special case those two failure conditions.
Please post if there are further questions.


Get Contract State returns incorrect data model

Current behavior
Calling RPC command get contractstate on a neo python node currently does not return the same data as neo-cli.
Using this RPC command
{
	"jsonrpc":"2.0",
	"method":"getcontractstate",
	"params":["33ee36c712b37df8acfbda4a1beb165e100ed3e0"],
	"id":1
}

will recieve this output
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "version": 0,
    "code": {
      "hash": "0x33ee36c712b37df8acfbda4a1beb165e100ed3e0",
      "script": "SCRIPT_OMITTED",
      "parameters": "0710",
      "returntype": 7
    },
    "name": "Stroage",
    "code_version": "1",
    "author": "THEKEY",
    "email"<EMAIL_ADDRESS>    "description": "THEKEY",
    "properties": {
      "storage": true,
      "dynamic_invoke": false,
      "payable": false
    }
  }
}

Expected Behavior
The desired result should be the same one as NEO CLI node
"result": {
    "version": 0,
    "hash": "0x33ee36c712b37df8acfbda4a1beb165e100ed3e0",
    "script": "SCRIPT_OMITTED",
    "parameters": [
      "String",
      "Array"
    ],
    "returntype": "String",
    "name": "Stroage",
    "code_version": "1",
    "author": "THEKEY",
    "email"<EMAIL_ADDRESS>    "description": "THEKEY",
    "properties": {
      "storage": true,
      "dynamic_invoke": false
    }
  }
}

How to reproduce
Execute the RPC command in any client like insomnia by targeting a neo python node like
http://node2.nyc3.bridgeprotocol.io:10332
Your environment
No relevant

Thanks for the report!
So to summarise;

there is no result.code object anymore
result.parameters is now a list of argument type name strings
result.returntype is now a argument type name string
result.properties object does not have a payable key. (I actually think we should keep this, as I'm sure that will get added to neo-cli sooner or later)

@jseagrave21

@ixje I am working on this now.

@saltyskip fixed in dev branch thanks to @jseagrave21 👍