Pull Request Merge Queue Public Beta Feedback

[willsmythe]

We want to hear from you on how we can improve pull request merge queue, now in public beta for repos on GitHub Enterprise Cloud and open source organizations! 🎉 See the changelog for more details.

Let us know how we can make the feature work better for you!

👉 Important: configuring your CI

Before enabling merge queue for a branch, make sure your CI is configured to build the temporary branches created by the queue. This is the most common problem we're seeing.

For GitHub Actions, add merge_group as a trigger (under on) to ensure this workflow is run for queue-created branches

For other CI services, you may need to update your branch filters or triggers to build branches starting with the prefix gh-readonly-queue/{base_branch}/

See the docs for more details.

🐛 Known issues

Some of the more common or noteworthy issues we are tracking:

• Actions workflows not triggering on merge_group (fixed)
• @depdendabot merge command does not working (Dependabot team is evaluating)

🚀 Top feature requests

• API to enqueue/dequeue and view queue
• Require different status checks for a PR's entry into the queue vs. for merging by the queue

[mayank99]

One thing I noticed immediately is that when clicking on "Merge when ready", it doesn't allow specifying the commit message/description.

This can be alleviated to an extent by changing the default commit message to use the PR title/description, but that's not ideal.

[magicus]

We have tried using merge queues, and moved off them again, simply because this functionality was missing. We tried enabling them again right now, hoping this would have been fixed, but alas, it had not, so we had to disable them again. :-(

To me, this is the single biggest outage in the merge queue functionality. Please prioritize implementing it. And perhaps ping this thread when it's done..? 😍

[jasongornall-dd]

Any updates on support for this?

[xun-guo-anzx]

Would be good if merge queue can make customised auto-merge commit message set up via API: https://docs.github.com/en/graphql/reference/mutations#enablepullrequestautomerge to persist.

[dsmith3197]

My team is also waiting for this functionality. In the meantime, we have been using the PR title/description as a workaround.

One undesirable behavior we noticed is that markdown comments (e.g., from a PR template) are included in the commit message. From a UX point of view, I would personally expect the commit message to be the same as the visible PR description. Do you agree, and if so, is this something that we can change?

[sandstrom]

@willsmythe Great with the queue reaching public beta!

I've written some feedback on the Merge Queue a while back, when we tested it in the private beta. Didn't work for us (for the reasons mentioned in my feedback).

Awesome if you'd like to take a quick look and respond:

• Merge Queue Feedback: Support for semi-linear merge #14863

(in short, we want the queue to support a semi-linear history, something which e.g. AzureDevOps support, see https://devblogs.microsoft.com/devops/pull-requests-with-rebase/#semi-linear-merge)

---

While I have your attention, I'd also love to hear your thoughts on these two:

• Intelligent 'Dismiss stale approvals when new commits are pushed' #12876
• Support semi-linear history (rebase && merge --no-ff) #8940

(also related to PR workflow)

[kaste]

Ah, sh**, thought merge-queue is the semi-linear strategy on GitHub. 😄

[sandstrom]

@willsmythe Great, thanks! 🏅

Semi-linear merge support (in general, and in the queue) would make our team workflow that much better on Github 😄

---

For reference, this functionality also exist in Gitlab, illustrated as follows:

https://docs.gitlab.com/ee/user/project/merge_requests/methods/#merge-commit-with-semi-linear-history

[sandstrom]

@willsmythe Just checking in on this one, do you have any update on semi-linear merge support?

We'd love to start using the merge queue, but lack of semi-linear merge is a blocker for us.

I know semi-linear merges are supported in Gitlab, Azure Devops and Bitbucket. So I'm hoping Github would add support too 😄

[sandstrom]

@willsmythe Happy autumn! 🍂

Just wanted to check in to hear if you have any updates on semi-linear merge support?

[sandstrom]

Happy New Year! 🎆

Just checking in to see if there are any planned support for semi-linear merge?

That's the missing piece before we can start using the merge queue functionality.

[Methuselah96]

I'm trying out this feature in a sample repo, but the merge_group event never gets triggered for GitHub Action CI. The PRs just remain in the queue and never get merged. Any suggestions on what I'm missing?

[dogmatic69]

I've been trying to make queues work and have tried every combination of merge_group, pull_request_target and pull_request. Nothing got the jobs running...

Digging through here I saw that workaround for push with branches matching gh-readonly-queue/master/** and finally I get something happening.

Is there a regression to this issue?

[alex-statsig]

Our triggers are:

  push:
    branches: [main]
  pull_request:
    branches: [main]
  merge_group:
    branches: [main]

And this works fine for me. Only issue I've had is that the paths filtering is not available for merge_group. We were using the push approach a while back but started having issues with that (two PRs entering at the same time caused issues).

[dogmatic69]

which one is actually triggering it though? For me I could only make it happen with push. the queue does not create a PR so it should never trigger on pull_request.

merge_group, pull_request and pull_request_target did not trigger anything for me.

[scarf005]

can confirm this is still happening. workflow trigger used:

on:
  push:
    branches:
      - upload
    paths-ignore:
      - doc/**
      - 'scripts/**'
  merge_group:
  pull_request:
    branches:
      - upload
    paths-ignore:
      - doc/**
      - 'scripts/**'

[snowystinger]

I am not seeing the merge_group.checks_requested in "Recent deliveries" under webhooks. I assume that's why people are having issues. I do see merge_group.destroyed, so I'm fairly confident I'm set up correctly. I also have required checks on my branch protection, though I'm not sure that's needed.

All that to say, I'm unable to trigger my checks.

Edit: I found my issue, I needed to have an actual check for required checks to run. Now I get the webhook delivery.

[nelsonjchen]

I'm not quite sure why this is limited to organizations. That seems arbitrary. Individual users could use them.

Dependabot notices come in waves for me so tossing them all into a merge queue would be awesome.

[abernier]

I agree many popular repos (which probably need a merge-queue the most) are often created on a personal repo first(eg mrdoob/three.js), and stay like this then.

I wanted to set this up for yomotsu/camera-controls but can't due it is also a personal repo :(

Would be great if we could opt-in even for personal repos 🚀

[elasticdog]

There are a lot of communities (such as Rust), where it's common to use a merge bot for this functionality because it is such an important method of enforcing the not rocket science rule with minimal friction. One of the more popular bots Bors-NG, has now been officially deprecated and the publicly hosted instance will be going away. Being affected myself, I attempted the switch to merge queues for a personal open source project, before I realized that they were limited to organizations.

Is this just a beta limitation, or do you plan on eventually opening merge queues up for personal repos as well?

[maxdeviant]

Is there a way to view historical merges in the merge queue? It would be useful to see which PRs were merged as part of the same group, for instance.

[willsmythe]

Not currently, but we are planning some UX improvements, including a "recent activity" timeline.

[dustinblanchard]

This isn't working for us at all. The checks are staying on pending for every PR even though they completed on them prior to entering the Queue and they are added to our workflow file as:

on:
  pull_request:
    branches: [main, production]
  merge_group:
    types: [checks_requested]

[kdawgwilk]

@jiffyclub Looks like a fix was merged in soon after https://github.com/orgs/community/discussions/46757#discussioncomment-4926252

[willsmythe]

@jiffyclub - let us know if you're still seeing a problem. This issue was causing Actions workflows using merge_group to not trigger in a large number of repo.

@kdawgwilk - thanks 😄

[RCheesley]

We have this issue as well - all our PRs are being removed from the queue un-merged saying that the checks have not been reported in time. They never seem to start or complete.

[alexnb]

Our PRs seem to stay in the queue several times (each time after successful checks), every time with a merge resulting on main. Sometimes though, this loop stops and PR disappears from the queue.

[big-andy-coates]

Seeing the same issue.

Is the on.merge_group shown in the example above required to use merge queues?

I can't see any mention of it in the docs: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions
Nor in the blog post linked to from the "Try merge queues" pop up I got: https://github.com/creek-service/creek-service#:~:text=with%20merge%20queue!-,Learn%20more,-about%20how%20to

[nwalters512]

Super excited to see this in public beta!

Over on PrairieLearn/PrairieLearn#7131, after adding a PR to the merge queue, removing it, then adding it again, I see a weird commit:

If I click on the commit, there's a message that says "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." I've never seen this before, so I can only assume that this is something to do with merge queues.

I'm also facing the same issue others are reporting where the checks never run.

[willsmythe]

If I click on the commit, there's a message that says "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." I've never seen this before, so I can only assume that this is something to do with merge queues.

Thanks for reporting. We're tracking an internal issue for the "This commit does not belong" message.

I have opened a second issue for the "referenced this commit" event in the timeline (these events are not supposed to appear).

I'm also facing the same issue others are reporting where the checks never run.

A fix rolled out that addresses an issue with the merge_group webhook event and Actions trigger. See #46757 (reply in thread)

If this is different than the problem you're seeing, can you start a new thread below and provide more details (what CI service are you using, if any status checks are reported, did you update your CI configuration to either trigger on merge_group or on push to the temporary branches created by the queue, etc).

[nwalters512]

Glad to hear your tracking those other two issues internally!

I'm still experiencing issues with the merge_group Actions trigger. I'll share more details in #46757 (comment) to try to keep that discussion in one place!

[willsmythe]

A fix just rolled out for the merge_group trigger. Give it another try and let us know!

[nwalters512]

@willsmythe looks like it's working now, thanks for getting that fixed!

[SanjayVas]

I'm trying to figure out the behavior w.r.t. to the "Merge method" setting. My goal is to have each PR result in a single revision to the base branch, so I currently have PRs set to squash. The base branch has a protection to enforce linear history.

What "Merge method" setting for merge queues will ensure that each PR in the queue still ends up as exactly one revision? I am concerned that e.g. "Squash and merge" here implies squashing all of the PRs in the queue into a single revision.

[willsmythe]

Good question. If you configure merge queue to use "squash and merge", each pull request will be represented by its own commit regardless of the number of pull requests the queue merges in a single operation.

[nwalters512]

Thanks for confirming! It'd be great to see this called out in the docs, as I had the same question. I'm glad to see that it does keep each individual commit.

[marcind]

+1, I assumed that the entire merge group would've been squashed together as one big commit

[willsmythe]

Cool. We'll make this clearer in the docs!

[marcind]

I'd suggest updating the wording in the settings UI. Make it clear that the selected merge strategy will be applied to each individual PR, not the group as a whole

[marcind]

I'm using a workflow to validate that every PR title matches conventions (using https://github.com/amannn/action-semantic-pull-request). The status check this action adds is configured as required for the target branch.

Having this setup causes the merge queue to stall, because the workflow never runs and the check is never set. That's because the workflow is configured to run only on pull_request triggers, which is because the action actually requires access to the PR metadata to do it's job. I can update the workflow to also run on push and merge_group (once that gets fixed), but at that point the action fails because it doesn't have a way to tell what PR it's supposed to validate.

What is the recommendation for having validation against the PR itself?

[vext01]

Sorry, I meant to say:

We only run the tests on the sum of the queued PRs. Not on each PR in isolation.

[vext01]

For those who want different status checks at different times (like with bors-ng) and you are using a self-hosted CI, I've written up a hack I used to achieve that here:
https://theunixzoo.co.uk/blog/2023-11-16-migrating-to-gh-merge-queues.html

[ro-savage]

Looks like this isn't been actioned by Github. We are downgrading back off enterprise because Merge Queues don't work at all for us when requiring both PRs and Merge Queues to have the same required tests.

For future reference - We want our E2E test to run only on Merge Queues and our PRs to run the other tests.

We have 40+ E2E tests, and creating 40+ fakes ones that all pass on the PR is both not practically and doesn't work because we want people to optionally be able to run the E2E via tags.

Feels like Merge Queues has been created then abandoned with feedback not taken seriously.

[jduan-highnote]

Everyone at github.com is presumably working on AI related initiatives 😞

[sehz]

You can have different test for PR and Merge Queue.

[austin-schmolz]

If I try to set the "Status check timeout" to anything more than 127, it returns a 500 error. 7-bit setting?

I don't see this limit referenced in the documentation anywhere.

[willsmythe]

Thanks for reporting. We're looking into it.

[willsmythe]

A fix for this just rolled out. There was a disconnect between the DB column type (TINYINT) and the front-end validation. You can now specify a value up 360 (6 hours).

Note: I updated my reply re: 0 (no timeout) since this is not how the queue currently behaves with this value 😄 . We're evaluating.

[zhang297]

@willsmythe is there a reason why the timeout value is capped at 360? I have merge checks take slightly longer than 6 hours sometimes. Any workaround for that?

[Thunderforge]

When a PR is in a merge queue, one of the options in the … is "Jump queue". If I choose it, I get the question

Are you sure you want to force #XYZ to jump the queue? [Cancel] / [Yes, jump the queue]

I have no idea what it means to "jump the queue". Does it mean it merges immediately? Does it mean it is removed from the queue and goes back to an unmerged state? Something else?

I also checked what I thought was the documentation on merge queues and didn't see anything related to that.

[UelitonFreitas]

Will the merge queue make it available to "jump" a pull request by selected people?
We have cases where we only want certain people to be able to "jump" PRs. This way we can ensure that the merge queue is not impacted by everyone clicking in "jump" button at same time.

[jonaslindstr]

I agree with the OP that "jump the queue" might not be universally understood. At dictionary.cambridge.org it is marked with "idiom UK usually disapproving" so perhaps a different wording could be considered.

[parky128]

"Move to Front", 'Bring to Front" could would in terms of terminology - a bit like how in image editing programs where you are dealing with multiple layers and you want to bring something up the layer levels.

[changusmc]

Jumping is useful if you have a pull request that needs to get merged ASAP

How does jumping the queue help with getting a PR merged ASAP? That PR would still need to finish the merge group checks, it is no faster being in the front or back of the queue. The only thing that could affect merge-ability is if the checks are flaky.

I also want to echo restricting "jump queue" to admins.

[abchau]

Please use simple english instead of inventing a new terminology that only your team understand

[Thunderforge]

If I click "Merge when ready" on a PR, it goes into a merge queue.

But if I have a Dependabot PR and comment @dependabot merge, Dependabot gives the comment a thumbs up, but does not add the PR to the merge queue and the PR remains open.

If this is expected behavior (like it's waiting until the queue is cleared or something), that is not being communicated. I would hope that either GitHub or Dependabot would explain when it will be added. If it's a bug instead, I hope it will be fixed.

[willsmythe]

Moving comment from @jglick (https://github.com/orgs/community/discussions/46757#discussioncomment-5411001):

I noticed that there does not seem to be Dependabot integration yet: @dependabot merge is greeted with a 👍 but nothing happens and you need to add the PR to the queue yourself. (example: jenkinsci/build-token-root-plugin#123 (review)) I expected there to be a @dependabot enqueue command or something like that.

[jglick]

I have also experimented with Dependabot plus merge queue on Golang repos. It does not seem to work well. I turned off Require branches to be up to date before merging in my branch rule, since I did not want DB automatically rebasing every PR every time something else gets merged (which would make load on the CI system quadratic in the number of open PRs, unacceptable when builds are not cheap). That did not seem to be honored consistently—sometimes DB would still rebase a PR that did not seem to need it; and often it does not rebase a PR that clearly does, due to merge conflicts with the current trunk (never mind the queue!), forcing you to manually @dependabot rebase. But DB PRs for Golang update transitive dependencies, so if you have more than couple bumps open, they are likely to at best overlap in go.mod and frequently conflict; and they are almost certain to have merge conflicts in go.sum even if the bumps are truly unrelated, just because all the lines of text are close together. Also a PR with no conflicts with the current trunk but conflicts with the queue will get kicked out of the queue, and even if DB fixes the conflicts after trunk has been updated, it will not get automatically readded to the queue. The result of all this is that while you can get one DB PR merged, it is likely that all the rest will wind up with conflicts or supposedly green but removed from the queue, and so you then need to wait for the first PR to be merged and then go back and pick the next one you want to add to the queue—defeating the purpose of a merge queue, that you can just add a bunch of stuff and go to lunch.

[timothyfroehlich]

I'm hitting this as well and it's been pretty annoying. Does anyone have a workaround for this? At least such that I can manually submit dependabot PRs without disabling merge queues?

[maciej-chime]

@willsmythe can you please comment on this? Is there an ETA for when this is going to be resolved?

[ryan-dahlia]

Has anyone had any luck getting Dependabot working with the merge queue? I'm experience similar issues to those reported above: inconsistent rebasing behavior and subsequent merge conflicts.

[OneCyrus]

merge queues are a great idea until we hit limitations in the required workflow logic. Really there should be a „require all triggered workflows to succeed“ before merging. See here: https://github.com/orgs/community/discussions/13690

otherwise we still need manual approval for each PR as we need to wait for optional workflows to complete.

[willsmythe]

Thanks for raising (or re-raising) this 😄.

As mentioned in #46757 (reply in thread), we are exploring different options around required status checks. The suggestion of a simple "require any check that reports status to pass" makes sense and would be useful (regardless of whether merge queue was involved or not).

[Thunderforge]

Our projects integrate with Jetbrains TeamCity. The Pull Requests build feature (a.k.a. pre-commit builds) doesn't work with this at all. When a PR goes into the merge queue, the new builds with the latest changes are never triggered.

Unfortunately, that's going to be a dealbreaker for us for adopting merge queues. I hope that GitHub will collaborate with Jetbrains and other CI toolchain providers so that this feature can be supported.

[willsmythe]

Thanks for raising this. We'll reach out to TeamCity on this.

For context, although merge queue is part of the pull request workflow, it never actually updates the pull request (other than to mark it as merged) or generates pull_request webhook events (which may CI services listen for). Merge queue creates temporary branches that include changes from one or more queued pull requests and generates traditional push webhook events and merge_group webhook events (which are new and specific to merge queue). Each CI service will need to decide how they want to integrate and work with merge queue (and we're happy to help with this!).

[alexnb]

We also use TeamCity and our PRs seem to stay in the queue several times (each time after successful checks), every time with a merge resulting on main. Sometimes though, this loop stops and PR disappears from the queue.

[justin-brown3]

@willsmythe any idea on the naming convention for those temporary branches?

[apgosar]

Some more documentation for integration with Jenkins will be really helpful.

[vext01]

I'd also really appreciate better documentation for working with self-hosted CI systems.

[sandstrom]

It's one year since this beta was launched!

I'm curious, do you have any plans for adding support for semi-linear merge to the merge queue?

Gitlab is working on adding support for their Merge Train functionality (same as Merge Queue).

---

Source: https://about.gitlab.com/direction/verify/merge_trains/#what-we-are-currently-working-on

cc @willsmythe

[air3ijai]

We should be able to click and jump to the check workflow which currently is executing

[jeremy-daley-kr]

What's the level of effort to allow an admin bypass to still run in the merge queue? Some PR's we want to allow bypassing CODEOWNER restrictions, but still want the merge queue workflow checks to catch race conditions.

[MichaelJJ]

One of our repos has a branch protection rule that matches all "**/*" and prevents branch pushes. We have to do this, because we want users with forked PRs to merge PRs after approvals are done, but don't want them to create branches directly in the repo (the user must have write access to merge).

It seems this breaks the merge queue functionality because the bot can't push to branches. We don't seem to be able to exempt the bot from the branch rule (it doesn't pop up in the auto-complete). Can we get the ability to exempt the bot, or just have it done automatically?

We can't exclude the special merge queue branch, because users could push to a branch with that prefix.

[OneCyrus]

Is there any up to date information regarding path-filtering support for merge queues (merge_group) in workflow definitions? It's very unfortunate not being able to use path-filtering and running so many unneeded workflows. all the time saved with merge queues is regained with way too much workflows in the queues waiting to run.

[OneCyrus]

@willsmythe this seems a real blocker for most organizations to even use merge queues. any chance you can give some feedback why this is that way and if we can expect this in the future? or if we should declare merge queues not compatible with our use cases?

[endakelly]

I think we're having the same issue as @OneCyrus whereby our merge queue never triggers our Azure DevOps pipeline because we have it set to trigger on certain paths and editing a file outside those paths causes the merge queue to just get stuck.

trigger:
  branches:
    include:
      - master
      - gh-readonly-queue/*
  paths:
    include:
      - pipeline.yml
      - terraform/

This makes merge queues not work for us in this specific scenario. Even being able to pass a check_skipped event or something would be helpful.

[JossWhittle]

To second @OneCyrus PLEASE expedite path-filtering!

Merge groups are not useable for so many repositories because of this.

We've been patiently waiting for a very very long time for this feature now this has got to become the priority.

[uidv8254]

Is it possible to add a "fast forward" option?

We have some time consuming checks and repeating them if it is not necessary should be avoided. If a PR is up to date, the content of the merge commit should be identical with the last commit on the PR.

In this case (The content is identical and all required checks were already passed) merge queue should handle this case similarly to a "fast-forward" in git.

[chris-grabcad]

One thing that we'd like is the ability to manage a merge queue on a branch via API calls such as we can do for most branch protection rules.

Our workflow is to cut a release branch and then protect that - we do allow point releases during a stabilization period and at this point we would also like to have the merge queue ON for the release branch.

We have automation to cut and protect the release branch, but right now we have to manually go in and add the merge queue to our release branch.

[purajit]

https://github.blog/changelog/2023-04-19-pull-request-merge-queue-public-beta-api-support-and-recent-fixes/#api-support

[lesaux]

I don't want my pull request status checks to be run in the merge queue. It doesn't make sense to me to run my tests twice, feels like a waste of money.
How can I achieve this??

[purajit]

Currently the same way you'd do conditional required checks - create a duplicate check that runs only on merge_group that always returns true.

[air3ijai]

How can I achieve this??

As it was mentioned, for now we have only some workarounds - Merge queue specific checks #103114

This is a known and mentioned issue in the first post.

🚀 Top feature requestsTop feature requests

Require different status checks for a PR's entry into the queue vs. for merging by the queue

[lesaux]

Thanks for the trick. I wasn't aware of it, I thought job names needed to be unique. I will try it out!

Edit: Indeed this works! thank you for the solution.

[ybokobza]

Is there a workaround for this by using Jenkins instead of Github action?
I am blocked in the merge queue because of a status check that is not relevant to that.

[adadache]

Seems like organization rulesets doesn't respect the merge queue feature.

At least when I'm enabling "Restrict updates" with a Bypass configuration for a target branch, the ruleset will not allow for Bypass users to merge a Pull Request if a branch protection with merge queues is enabled.

EDIT:
What I'd expect, is that merge queues initiated by those on the bypass list are still allowed, initiated and eventually the PR is merged.

❌ See image below with enabled merge queue (branch protection rule):

✅ Disabled merge queue (branch protection rule):

[air3ijai]

Did a try to reproduce that, but can't find "Require merge queue" at the Organization rulesets level - do I miss something?

screenshots

Repository ruleset

Organization ruleset

Also, some reference from the documentation
Choosing which repositories to target in your organization

If a repository is targeted by a ruleset created at the organization level, only owners of the organization can edit the ruleset. However, people with admin access to the repository, or with a custom role including the "edit repository rules" permission, can create additional rulesets at the repository level. The rules in these rulesets will be aggregated with the rules defined at the organization level. The result is that creating a new ruleset can make the rules targeting a branch or tag more restrictive, but never less restrictive. For more information on creating rulesets, see "About rulesets."

Do you have rulesets defined at both levels, Repository and Organization?

[adadache]

Organization rulesets doesn't have merge queues.

This is about a situation when you have Organization rulesets to "restrict updates" applied at the org level, and one of your repositories use merge queues through repository rulesets or a repo level rule as a branch protection.

[smarts]

Is this still the place to provide feedback on merge queues? If not, where should I go?
If so:
One problem I have with them is that they don't give the option to provide a multi-line commit message like normal merges and rebase merges do. Providing extra context around commits is an invaluable tool, especially when it comes to things like bug fixes. Not just unformatted text, but commit trailers too.

[smarts]

That's unfortunate. The PR description can often contain things that are undesirable in a commit message (and vice versa). What I actually want is for the merge queue's merge to use the commit messages from the commits themselves, or at the very least do this when the queue is merging a single commit. I think this is similar to what is done when generating release notes for a GitHub Release, so there is some concept of this that already exists in the platform.

[praseodym]

You can also do that by selecting "Pull request title and commit details":

[smarts]

Is the configuration in the screenshot for merge queues? Or if it's not specifically for merge queues, does it also apply to merge queues?

[praseodym]

Is the configuration in the screenshot for merge queues? Or if it's not specifically for merge queues, does it also apply to merge queues?

The latter, we have only squash merges enabled with this setting and the merge queue is using that.

[praseodym]

And the merge method for the merge queue is configured as 'Squash and merge' in the repository ruleset:

[iamstarkov]

API to enqueue/dequeue and view queue

is it still only available in GraphQL and not available in Rest API?